Aegra IDOR CVE-2026-44504 Exposes Cross-Tenant Data in Shared

Executive Summary

Aegra, an open-source drop-in replacement for LangSmith Deployments, shipped a cross-tenant Insecure Direct Object Reference (IDOR) vulnerability in versions prior to 0.9.7. Tracked as CVE-2026-44504, the flaw allows any authenticated attacker on a shared Aegra instance to execute graph runs against another user's threads, read full checkpoint state, and inject arbitrary messages into conversation history — all by supplying a valid thread_id belonging to that user. The advisory was published via GitHub Security Advisory (GHSA-m98r-6667-4wq7) on 2026-05-14. No CVSS score has been assigned as of this writing, but the impact is straightforward: tenant isolation is absent in multi-user deployments.

Technical Analysis

The vulnerability resides in Aegra's authorization layer for thread-level operations. According to the advisory, the platform did not verify that the authenticated user making a request to a specific thread_id actually owned or had permission to access that thread. An attacker with a valid session could enumerate or guess thread_id values — which are typically UUIDs but may be predictable depending on generation logic — and then:

• Execute graph runs against the victim's thread, consuming compute resources and potentially manipulating the state of ongoing AI workflows.
• Read the full checkpoint state, which includes conversation history, intermediate results, and any data stored within the thread's context.
• Inject arbitrary messages into the conversation history, enabling data poisoning attacks or social engineering against the thread owner.

Aegra is designed for teams that need a self-hosted alternative to LangSmith's deployment and monitoring features. The shared-instance model, where multiple tenants (users or teams) operate on the same Aegra server, is the explicit use case described in the project's documentation. The advisory notes that the vulnerability only affects deployments with multiple authenticated users — single-user instances are not exposed to this risk.

The issue was introduced in the initial implementation of thread access control and persisted through version 0.9.6. The fix, released in version 0.9.7, adds a permission check that validates thread ownership before allowing read or write operations. The advisory credits an internal security review for discovery; no public proof-of-concept or exploitation in the wild has been reported as of May 15, 2026.

Mitigations & Recommendations

Administrators running shared Aegra instances should upgrade to version 0.9.7 or later immediately. The update is available via the project's GitHub releases and the standard package registries. For organizations that cannot upgrade promptly, the only effective workaround is to restrict Aegra to single-user deployments or isolate instances per tenant at the network level — for example, by running separate Docker containers behind a reverse proxy that enforces tenant-based routing. The advisory does not list any configuration-based mitigation that would block the IDOR without the code fix.

Defenders should audit Aegra access logs for anomalous thread_id requests — specifically, any pattern where a single user accesses a large number of distinct thread IDs in a short window, or where thread IDs are accessed in sequential or predictable order. Such activity may indicate enumeration attempts. However, because the IDOR bypasses authorization entirely, successful exploitation would appear in logs as normal thread access events, making detection difficult without application-layer monitoring.