CVE-2026-44504 — aegra-api
Fix: aegra/aegra#337CVE-2026-44504 is a CWE-285 vulnerability in aegra-api. A fix is available for aegra-api — see the affected versions and patch details below.
Aegra: Cross-user run injection in /threads/{thread_id}/runs (IDOR)
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- 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 CVE-2026-44504.
EPSS Exploitation Probability
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
aegra-apiReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
Description
Impact
Aegra deployments running 0.9.0 through 0.9.6 with multiple authenticated users on a shared instance are vulnerable to a cross-tenant IDOR. Any authenticated user (User A), given another user's thread_id (User B), can:
- Execute graph runs against User B's thread via
POST /threads/{thread_id}/runs,POST /threads/{thread_id}/runs/stream, orPOST /threads/{thread_id}/runs/wait - Read User B's full checkpoint state via the resulting run's
outputfield - Inject arbitrary messages into User B's conversation history (persisted in B's checkpoint)
- Hide their activity from User B's
GET /threads/{thread_id}/runslisting because the run carries A'suser_id
The streaming variant is worse — the first SSE event: values frame returns the entire prior messages array immediately on connection, no graph execution needed.
Thread IDs are UUIDs but leak through frontend URLs, server logs, observability traces, and shared links. Guessing is not required.
Patches
Fixed in 0.9.7. The three affected endpoints now perform an SQL-level user_id == authenticated_user.identity check before calling _prepare_run. When the thread exists but is owned by another user, the response is 404 Thread not found (matching the read-side pattern) to avoid leaking thread existence.
Workarounds
If upgrade is not immediately possible, register an @auth.on("threads", "create_run") handler that explicitly verifies thread ownership against the authenticated identity before allowing the operation. Without a handler, no built-in authorization runs on these write paths.
Example mitigation handler:
from langgraph_sdk import Auth
auth = Auth()
@auth.on("threads", "create_run")
async def enforce_thread_owner(ctx: Auth.types.AuthContext, value: dict):
# Look up the thread, raise 404 if not owned by ctx.user.identity.
# Implementation depends on your data layer.
...
Root cause
Aegra's authorization model delegates per-resource policy to user-defined @auth.on handlers. When no handler is registered, handle_event(...) returns None and the request proceeds (default-allow). Read endpoints in api/threads.py add a defense-in-depth user_id filter at the SQL layer, but the run-creation endpoints in api/runs.py skipped that filter. Result: out-of-the-box deployments without custom auth handlers were vulnerable.
Affected endpoints
POST /threads/{thread_id}/runsPOST /threads/{thread_id}/runs/streamPOST /threads/{thread_id}/runs/wait
Stateless variants (POST /runs, POST /runs/wait, POST /runs/stream) are NOT affected — they generate a fresh thread_id server-side and never accept a caller-supplied one.
Credits
- @JoJoTheBizarre — discovered and reported the vulnerability with a precise reproducer (#336)
- @victorjmarin and @jawhardjebbi — wrote the fix and added test coverage at unit, integration, and manual-auth e2e levels (#337)
Resources
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | aegra-api | ≥ 0.9.0&&< 0.9.7 | 0.9.7pip install --upgrade 'aegra-api==0.9.7' |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for aegra-api, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update aegra-api to 0.9.7 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-44504 is resolved across your whole dependency graph.
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.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-44504 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-44504. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-44504 in your dependencies?
O3 Security finds CVE-2026-44504 across PyPI dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.