Vulnerabilities in pkg:pypi/aegra-api

PACKAGE
Advisory Identifier: GHSA-m98r-6667-4wq7
Advisory Summary

CVE-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.

1 Known Advisory Record(s)
Package Vulnerability Intelligence

pkg:pypi/aegra-api

1 Known Advisory Record(s)

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

CVE Identifier CVE-2026-44504
GHSA Identifier GHSA-m98r-6667-4wq7
Severity HIGH
CVSS v3.1 Base Score N/A
CWE Classification CWE-639: Authorization Bypass Through User-Controlled Key
Affected Product Aegra api
Package Ecosystem PyPI
Published Date
Last Updated

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.

aegra-api fixed: 0.9.7
pip install aegra-api>=0.9.7
Verify Direct and Transitive Dependencies

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

## 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`, or `POST /threads/{thread_id}/runs/wait` - Read User B's full checkpoint state via the resulting run's `output` field - 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}/runs` listing because the run carries A's `user_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: ```python 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}/runs` - `POST /threads/{thread_id}/runs/stream` - `POST /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 - Issue: https://github.com/aegra/aegra/issues/336 - Fix PR: https://github.com/aegra/aegra/pull/337 - Release: https://github.com/aegra/aegra/releases/tag/v0.9.7

CVE-2026-44504 Affected Aegra api Versions

1 component(s)
Fixed Versions:
0.9.7
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?
CVE-2026-44504 is a security vulnerability in Aegra api involving Aegra has cross-user run injection in /threads/{thread_id}/runs (IDOR) under CWE-639: Authorization Bypass Through User-Controlled Key.
Which Aegra api versions are affected?
Affected versions include releases prior to 0.9.7 across affected packages: aegra-api.
What version fixes CVE-2026-44504?
Upgrading to 0.9.7 (or the latest patched release for your respective branch) resolves the vulnerability.
Is aegra-api affected?
Yes, aegra-api is affected in releases prior to 0.9.7. Upgrade your dependency to 0.9.7 or later.
What CWE is associated with CVE-2026-44504?
CVE-2026-44504 is classified under CWE-639: Authorization Bypass Through User-Controlled Key (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.).
How can I check PyPI dependencies for CVE-2026-44504?
Run the dependency tree command: 'pip show aegra-api'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "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"
  }
}