Vulnerabilities in pkg:pypi/aegra-api
PACKAGECVE-2026-44504 is a HIGH aegra has cross-user run injection vulnerability (CWE-639: Authorization Bypass Through User-Controlled Key) affecting Aegra api libraries in the PyPI ecosystem. The issue involves aegra has cross-user run injection in /threads/{thread_id}/runs (idor). Remediation is available by upgrading affected packages to version 0.9.7.
pkg:pypi/aegra-api
Vulnerability advisories affecting package pkg:pypi/aegra-api. Select an advisory below to view technical details or fixes.
| Advisory ID | CVE / NVD | Severity | Summary |
|---|---|---|---|
| GHSA-m98r-6667-4wq7 | CVE-2026-44504 | HIGH | Aegra has cross-user run injection in /threads/{thread_id}/runs (IDOR) |
CVE-2026-44504 at a Glance
How to Fix CVE-2026-44504
To remediate this vulnerability, upgrade all affected Aegra api dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.
pip install aegra-api>=0.9.7
Run the following command in your project directory to verify that all resolved dependencies use the patched release:
pip show aegra-api
How to Check if You Are Affected
To determine whether your Python environment is affected by CVE-2026-44504, inspect your installed packages using pip:
pip show aegra-api
Analyze the terminal output to locate any version of Aegra api in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.9.7), your application is affected.
Note: The pip show aegra-api command checks currently installed packages in your active Python environment.
Technical Details
Vulnerability Mechanism & Technical Analysis
This vulnerability is classified under CWE-639: Authorization Bypass Through User-Controlled Key, where the system's authorization functionality does not prevent one user from gaining access to another user's data or record by modifying the key value identifying the data. In Aegra api, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.
Source Advisory Statement
CVE-2026-44504 Affected Aegra api Versions
1 component(s)| Product / Package | Ecosystem | Affected Versions | Fixed Version |
|---|---|---|---|
|
aegra-api
|
PyPI |
≥ 0.9.0
< 0.9.7
|
0.9.7
|
References
Frequently Asked Questions
What is CVE-2026-44504?
Which Aegra api versions are affected?
What version fixes CVE-2026-44504?
Is aegra-api affected?
What CWE is associated with CVE-2026-44504?
How can I check PyPI dependencies for CVE-2026-44504?
Machine-readable OSV JSON
OSV v1.5 Schema
{
"schema_version" : "1.4.0",
"id" : "GHSA-m98r-6667-4wq7",
"modified" : "2026-05-14T20:53:21Z",
"published" : "2026-05-07T01:49:51Z",
"aliases" : [ "CVE-2026-44504" ],
"summary" : "Aegra has cross-user run injection in /threads/{thread_id}/runs (IDOR)",
"details" : "## Impact\n\nAegra 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:\n\n- Execute graph runs against User B's thread via `POST /threads/{thread_id}/runs`, `POST /threads/{thread_id}/runs/stream`, or `POST /threads/{thread_id}/runs/wait`\n- Read User B's full checkpoint state via the resulting run's `output` field\n- Inject arbitrary messages into User B's conversation history (persisted in B's checkpoint)\n- Hide their activity from User B's `GET /threads/{thread_id}/runs` listing because the run carries A's `user_id`\n\nThe streaming variant is worse — the first SSE `event: values` frame returns the entire prior `messages` array immediately on connection, no graph execution needed.\n\nThread IDs are UUIDs but leak through frontend URLs, server logs, observability traces, and shared links. Guessing is not required.\n\n## Patches\n\nFixed 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.\n\n## Workarounds\n\nIf 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.\n\nExample mitigation handler:\n\n```python\nfrom langgraph_sdk import Auth\n\nauth = Auth()\n\n@auth.on(\"threads\", \"create_run\")\nasync def enforce_thread_owner(ctx: Auth.types.AuthContext, value: dict):\n # Look up the thread, raise 404 if not owned by ctx.user.identity.\n # Implementation depends on your data layer.\n ...\n```\n\n## Root cause\n\nAegra'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.\n\n## Affected endpoints\n\n- `POST /threads/{thread_id}/runs`\n- `POST /threads/{thread_id}/runs/stream`\n- `POST /threads/{thread_id}/runs/wait`\n\nStateless 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.\n\n## Credits\n\n- @JoJoTheBizarre — discovered and reported the vulnerability with a precise reproducer (#336)\n- @victorjmarin and @jawhardjebbi — wrote the fix and added test coverage at unit, integration, and manual-auth e2e levels (#337)\n\n## Resources\n\n- Issue: https://github.com/aegra/aegra/issues/336\n- Fix PR: https://github.com/aegra/aegra/pull/337\n- Release: https://github.com/aegra/aegra/releases/tag/v0.9.7",
"severity" : [ {
"type" : "CVSS_V4",
"score" : "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N"
} ],
"affected" : [ {
"package" : {
"ecosystem" : "PyPI",
"name" : "aegra-api"
},
"ranges" : [ {
"type" : "ECOSYSTEM",
"events" : [ {
"introduced" : "0.9.0"
}, {
"fixed" : "0.9.7"
} ]
} ]
} ],
"references" : [ {
"type" : "WEB",
"url" : "https://github.com/aegra/aegra/security/advisories/GHSA-m98r-6667-4wq7"
}, {
"type" : "ADVISORY",
"url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-44504"
}, {
"type" : "WEB",
"url" : "https://github.com/aegra/aegra/issues/336"
}, {
"type" : "WEB",
"url" : "https://github.com/aegra/aegra/pull/337"
}, {
"type" : "WEB",
"url" : "https://github.com/aegra/aegra/commit/e1b2042254fd49072ca281bc35b3f2a3bed74b31"
}, {
"type" : "PACKAGE",
"url" : "https://github.com/aegra/aegra"
}, {
"type" : "WEB",
"url" : "https://github.com/aegra/aegra/releases/tag/v0.9.7"
} ],
"database_specific" : {
"cwe_ids" : [ "CWE-285", "CWE-639" ],
"severity" : "HIGH",
"github_reviewed" : true,
"github_reviewed_at" : "2026-05-07T01:49:51Z",
"nvd_published_at" : "2026-05-14T16:16:24Z"
}
}