Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
📦 npm🐍 PyPI
Not in CISA KEV

GHSA-f65r-h4g3-3h9h

GHSA-f65r-h4g3-3h9h is a CWE-358 vulnerability in @mcptoolshop/backpropagate. O3 Security confirms whether GHSA-f65r-h4g3-3h9h is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.

Backpropagate: backprop ui --auth and backprop ui --share do not enforce authentication

Also known asCVE-2026-48797PYSEC-2026-291
Published
Jun 26, 2026
Updated
Jun 29, 2026
Affected
2 pkgs
Patched
2 / 2
Exploits
None indexed
Exploitation data as of Aug 11, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

No confirmed exploitation observed yet

  • A successful exploit gives an attacker total control of the affected component, not partial access.
  • CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.

Exploitation and automatability from CISA’s SSVC triage for GHSA-f65r-h4g3-3h9h.

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs25th percentile — riskier than 25% of all scored CVEsHighest risk
0.00%0.27%0.55%0.82%0.3%0.3%0.3%Jul 26Aug 26Aug 26

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

Real-World Exposure

2 pkgs affected

How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched.

0other npm packages depend on this — each one inherits the vulnerability until it's patched upstream
@mcptoolshop/backpropagatenpm
61downloads / week

Description

Summary

In backpropagate >= 1.1.0, the optional Reflex web UI (pip install backpropagate[ui], launched via backprop ui) exposes a training control plane: dataset upload, model load, training start/stop, multi-run orchestration, GGUF export, and HuggingFace Hub push.

The CLI accepts two operator-facing flags intended as security controls:

  • --auth user:pass — documented as "require HTTP Basic authentication on every request to the UI."
  • --share — documented as "expose the UI on a public address; requires --auth."

When --auth user:pass is passed, the CLI prints Auth: enabled (user: <username>) to confirm to the operator that authentication is active, then exports BACKPROPAGATE_UI_AUTH=user:pass to the subprocess that launches the Reflex backend.

The Reflex backend (backpropagate/ui_app/**) never reads BACKPROPAGATE_UI_AUTH. No authentication middleware is registered. No request-level guard runs. No WebSocket upgrade guard runs. Any client that reaches the bound port — local or remote, depending on whether --share is used — has full UI access.

An inline comment at backpropagate/cli.py:1217-1218 in the v1.1.0 source documents the gap: "For Phase 1 the variable is exported but Reflex doesn't read it yet." This comment was internal-facing; the user-facing documentation (README, CHANGELOG, SHIP_GATE) advertised the contract as enforced.

This advisory is filed primarily because the runtime contradicted an operator-facing security claim. Code-only bugs of comparable shape (auth check missing entirely from a path) would already warrant disclosure; the additional false-promise dimension raises the severity.

Impact

An attacker who reaches the bound port can:

  • Read uploaded datasets rendered in the UI preview, including content of any JSONL/CSV/TXT file the legitimate operator has uploaded for fine-tuning.
  • Trigger arbitrary training runs against any base model the operator has installed locally or that can be downloaded from HuggingFace.
  • Trigger HuggingFace Hub pushes to repositories named via the UI input (subject to the operator's local HF token's scope — typically all repos owned by the operator).
  • Cause disk-fill DoS via the rx.upload endpoint (no size cap, no extension filter, no per-session count cap in v1.1.0 / v1.1.1).
  • Read model paths (source_model_path, dataset_path, model, uploaded_path) which are user-supplied and bypass the safe_path() helper that lives in backpropagate/ui_security.py (path validation is dead code on the Reflex surface in v1.1.0 / v1.1.1).

The combination of unauthenticated training control, HF push target spoofing, and path-input traversal makes the affected endpoint suitable for both data exfiltration (reading uploaded training data) and supply-chain attacks (pushing tampered model weights to the operator's HF account).

The local-only default (no --share) reduces exposure to a host-local attacker. The --share flag is documented as a "public URL" feature; operators who used --share --auth user:pass had no warning that the auth half was inert.

Patches

Fixed in v1.2.0 (released 2026-05-23). The patch implements real ASGI middleware via rx.App(api_transformer=basic_auth_transformer) that gates HTTP routes AND the /_event WebSocket upgrade. Four modes (no_auth_local_only / token_auto / explicit_creds / production), HMAC-signed cookie validated PRE-websocket.accept(), Host + Origin allowlists. The middleware ships alongside a 4-layer defense in depth at the cli.py / ui_app/app.py / rxconfig.py / env-strip surfaces so direct python -m reflex run invocations (bypassing the CLI guard) also enforce authentication.

Upgrade with:

  • pip: pip install --upgrade backpropagate
  • npm: npm install -g @mcptoolshop/backpropagate@latest

Full release notes: https://github.com/mcp-tool-shop-org/backpropagate/blob/main/CHANGELOG.md#120---2026-05-23

Workarounds

If users cannot upgrade immediately:

  1. Do not pass --auth or --share to backprop ui. Run the UI with no flags (backprop ui); it will bind to localhost and accept any client that can reach 127.0.0.1.
  2. For remote access, use SSH port-forwarding instead of --share:
    # On the client:
    ssh -L 7860:localhost:7860 <training-host>
    # On the server:
    backprop ui            # no --share
    # Then open http://localhost:7860 in your local browser.
    
    SSH provides the authentication layer the Reflex UI did not.
  3. Audit existing deployments. If any host running backpropagate >= 1.1.0 has previously been launched with --share, treat any uploaded training data, model paths, or HF push targets visible in that UI session as potentially exposed. Re-issue HF tokens that have been in use during such sessions.

Binary distribution gap. Standalone binaries (Windows .exe / macOS .app via PyInstaller) failed to build for v1.2.0 and will land in a follow-up patch release. In the interim, users who relied on the v1.1.x binary distribution should install the patched version via pip install backpropagate==1.2.0 to receive the auth-bypass fix. The v1.2.0 PyPI package and @mcptoolshop/[email protected] npm package both carry the patched code.

Credit

Discovered by the dogfood-swarm Stage A audit on 2026-05-22 (finding ID FRONTEND-A-001, classified CRITICAL). The audit also surfaced contradicting documentation in CHANGELOG / SHIP_GATE / README; those were corrected in v1.2.0 alongside the runtime fix.

Affected Packages

2 total 2 fixed
EcosystemPackageVulnerable rangeFix
📦npm@mcptoolshop/backpropagate1.1.0&&< 1.2.01.2.0
🐍PyPIbackpropagate1.1.0&&< 1.2.01.2.0

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @mcptoolshop/backpropagate. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update @mcptoolshop/backpropagate to 1.2.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-f65r-h4g3-3h9h is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-f65r-h4g3-3h9h is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-f65r-h4g3-3h9h. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## Summary In `backpropagate >= 1.1.0`, the optional Reflex web UI (`pip install backpropagate[ui]`, launched via `backprop ui`) exposes a training control plane: dataset upload, model load, training start/stop, multi-run orchestration, GGUF export, and HuggingFace Hub push. The CLI accepts two operator-facing flags intended as security controls: - `--auth user:pass` — documented as "require HTTP Basic authentication on every request to the UI." - `--share` — documented as "expose the UI on a public address; requires `--auth`." When `--auth user:pass` is passed, the CLI prints `Auth: enabl
O3 Security · Impact-Aware SCA

Is GHSA-f65r-h4g3-3h9h in your dependencies?

O3 detects GHSA-f65r-h4g3-3h9h across npm, PyPI dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

GHSA-f65r-h4g3-3h9h: @mcptoolshop/backpr… | O3 Security