Summary
Aegra has cross-user run injection in /threads/{thread_id}/runs (IDOR)
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
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.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
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.
Frequently Asked Questions
- What is CVE-2026-44504? CVE-2026-44504 is a high-severity security vulnerability in aegra-api (pip), affecting versions >= 0.9.0, < 0.9.7. It is fixed in 0.9.7.
- Which versions of aegra-api are affected by CVE-2026-44504? aegra-api (pip) versions >= 0.9.0, < 0.9.7 is affected.
- Is there a fix for CVE-2026-44504? Yes. CVE-2026-44504 is fixed in 0.9.7. Upgrade to this version or later.
- Is CVE-2026-44504 exploitable, and should I be worried? Whether CVE-2026-44504 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-44504 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-44504? Upgrade
aegra-apito 0.9.7 or later.