AI Threat Alert
A logic flaw in langgraph-api's run-creation path let it skip the same authorization check used everywhere else in the assistant lifecycle, so a request to create a run could silently reference another tenant's private assistant and return its metadata, config, and context — fields the runtime encrypts at rest precisely because they can hold secrets and business logic. This only bites deployments that wrote custom authorization handlers gating access via an assistants.search or assistants.read handler without a global fallback, which narrows exposure but is a common pattern for multi-tenant LangGraph Server / Agent Server deployments. There's no public exploit, no KEV listing, and CVSS 5.9 (AC:High, PR:Low) reflects that this requires an authenticated user and specific handler misconfiguration rather than a trivial remote bypass — but the confidentiality hit (C:H) is real given 3,763 downstream dependents on the package. Patch to langgraph-api 0.10.0, then re-verify: handlers gating only via assistants.search must add an equivalent assistants.read handler returning the same owner filter, or the run-creation path silently goes unchecked again post-upgrade. Audit run-creation logs for cross-tenant assistant references and rotate any credentials that may have lived in exposed assistant config.
What is the risk?
Medium severity (CVSS 5.9) reflecting high confidentiality impact offset by high attack complexity and required low privileges — this is not a remote, unauthenticated bypass. Exploitability is conditional: only deployments with custom authorization handlers that gate assistant access exclusively through `assistants.read` (or `assistants.search`) without a global fallback handler are affected. No public exploit code, no Nuclei template, not in CISA KEV, and the vendor states no evidence of in-the-wild exploitation. The main risk driver is silent scope: teams may not realize their handler wiring has this specific gap until an authenticated user (possibly a legitimate but lower-trust tenant) probes for it.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| LangGraph | pip | < 0.10.0 | 0.10.0 |
Do you use LangGraph? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 step-
Upgrade to langgraph-api 0.10.0 or later, which unifies run/cron creation onto the
assistants.readevent (matching direct reads) and stops forwarding client-supplied metadata into that authorization check. If you run custom authorization handlers, explicitly verify parity: any handler that previously gated assistant access only viaassistants.searchduring run creation must be replaced or supplemented with an equivalentassistants.readhandler returning the same owner-style filter — this is a breaking behavioral change, not just a patch-and-forget. Post-upgrade, audit application logs for run/cron-creation requests that reference assistant IDs outside the requesting user's ownership scope, and rotate any secrets embedded in assistantconfig/metadata/contextfields for tenants who may have been exposed prior to patching.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-55236?
A logic flaw in langgraph-api's run-creation path let it skip the same authorization check used everywhere else in the assistant lifecycle, so a request to create a run could silently reference another tenant's private assistant and return its metadata, config, and context — fields the runtime encrypts at rest precisely because they can hold secrets and business logic. This only bites deployments that wrote custom authorization handlers gating access via an assistants.search or assistants.read handler without a global fallback, which narrows exposure but is a common pattern for multi-tenant LangGraph Server / Agent Server deployments. There's no public exploit, no KEV listing, and CVSS 5.9 (AC:High, PR:Low) reflects that this requires an authenticated user and specific handler misconfiguration rather than a trivial remote bypass — but the confidentiality hit (C:H) is real given 3,763 downstream dependents on the package. Patch to langgraph-api 0.10.0, then re-verify: handlers gating only via assistants.search must add an equivalent assistants.read handler returning the same owner filter, or the run-creation path silently goes unchecked again post-upgrade. Audit run-creation logs for cross-tenant assistant references and rotate any credentials that may have lived in exposed assistant config.
Is CVE-2026-55236 actively exploited?
No confirmed active exploitation of CVE-2026-55236 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-55236?
Upgrade to langgraph-api 0.10.0 or later, which unifies run/cron creation onto the `assistants.read` event (matching direct reads) and stops forwarding client-supplied metadata into that authorization check. If you run custom authorization handlers, explicitly verify parity: any handler that previously gated assistant access only via `assistants.search` during run creation must be replaced or supplemented with an equivalent `assistants.read` handler returning the same owner-style filter — this is a breaking behavioral change, not just a patch-and-forget. Post-upgrade, audit application logs for run/cron-creation requests that reference assistant IDs outside the requesting user's ownership scope, and rotate any secrets embedded in assistant `config`/`metadata`/`context` fields for tenants who may have been exposed prior to patching.
What systems are affected by CVE-2026-55236?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, multi-tenant SaaS agent platforms, authorization/access control layers.
What is the CVSS score for CVE-2026-55236?
CVE-2026-55236 has a CVSS v3.1 base score of 5.9 (MEDIUM).
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0083 Credentials from AI Agent Configuration AML.T0084 Discover AI Agent Configuration Compliance Controls Affected
What are the technical details?
Original Advisory
## Summary In affected versions of `langgraph-api` (the LangGraph Server runtime), the run-creation path authorized the assistant attached to a run using a different authorization event than the rest of the assistant-handling code paths. Direct assistant reads and cron creation dispatch the `assistants.read` authorization event; run creation dispatched `assistants.search` with an incomplete value. In deployments whose custom authorization handlers register only an `assistants.read` handler (without an `assistants.search` handler and without a global fallback handler), no handler was consulted on the run-creation path, the returned filter set was empty, and the owner constraint was omitted from the resulting query. As a result, in those deployments a request to create a run could reference a private assistant owned by another user, even where direct assistant reads, assistant search, and cron creation against that assistant were correctly denied. The run-creation response merged the referenced assistant's `metadata`, `config`, and `context` into fields returned to the requesting user. These fields can carry sensitive configuration; the runtime encrypts them at rest for that reason. We have no evidence of this behavior occurring in the wild. ## Affected users / systems You may be affected if you: - run `langgraph-api` (the LangGraph Server / Agent Server runtime, including via the LangGraph Platform Helm chart), and - use custom authorization handlers that gate assistant access through an `assistants.read` or `assistants.search` handler rather than a global handler covering all assistant events. Deployments without custom authorization handlers, or whose handlers apply an equivalent owner filter across all assistant events (for example through a global handler), are not affected. ## Impact - Confidentiality: exposure of another user's private assistant `metadata`, `config`, and `context` through the run-creation response. These fields can contain sensitive configuration. - Integrity: creation of a run associated with another user's private assistant, beyond the requesting user's authorization scope; the run is then carried out using that assistant's configuration. ## Patches / mitigation Run creation, and the parallel cron-creation path, now dispatch the `assistants.read` authorization event in both the in-memory and gRPC/Postgres runtimes, matching direct assistant reads. Client-supplied run and cron metadata is no longer forwarded into that authorization event, so handlers receive a consistent value shape and determine access by returning an owner filter that is applied server-side. Fixed in `langgraph-api` 0.10.0. This is a behavioral change for deployments with custom authorization handlers: - Handlers that gated assistant access only through `assistants.search` during run creation are no longer consulted on that path; provide an equivalent `assistants.read` handler that returns the same owner filter. - The metadata field on the `assistants.read` event during run and cron creation is no longer populated; handlers that read or stamped it should move that logic into the run/cron create handlers. ## Operational guidance - Register an `assistants.read` handler (or a global handler covering it) that returns an owner-style filter, and confirm parity across the assistant read, search, and run/cron creation paths. - Upgrade to a release containing this change.
Exploitation Scenario
In a multi-tenant SaaS platform built on LangGraph Server, Tenant A configures a private assistant whose `config` embeds a downstream API key and a proprietary system prompt. The platform's custom authorization layer only registers an `assistants.read` handler (a reasonable-looking implementation choice) without a matching `assistants.search` handler or global fallback. Tenant B, an authenticated but unrelated user, issues a run-creation request that references Tenant A's assistant ID — a value Tenant B could guess, enumerate, or obtain from a shared link. Because run creation dispatched `assistants.search` rather than `assistants.read`, no handler is consulted, no owner filter applies, and the platform both executes a run using Tenant A's assistant configuration and returns that configuration's `metadata`/`config`/`context` in the API response to Tenant B — exposing the embedded API key and prompt logic to an unauthorized party.
Weaknesses (CWE)
CWE-285 — Improper Authorization: The product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action.
- [Architecture and Design] Divide the product into anonymous, normal, privileged, and administrative areas. Reduce the attack surface by carefully mapping roles with data and functionality. Use role-based access control (RBAC) to enforce the roles at the appropriate boundaries. Note that this approach may not protect against horizontal authorization, i.e., it will not protect a user from attacking others with the same role.
- [Architecture and Design] Ensure that you perform access control checks related to your business logic. These checks may be different than the access control checks that you apply to more generic resources such as files, connections, processes, memory, and database records. For example, a database may restrict access for medical records to a specific database user, but each record might only be intended to be accessible to the patient and the patient's doctor.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N References
Timeline
Related Vulnerabilities
CVE-2025-8709 7.3 langgraph-checkpoint-sqlite: SQL Injection exposes database
Same package: langgraph CVE-2025-67644 7.3 langgraph-checkpoint-sqlite: SQL Injection exposes database
Same package: langgraph CVE-2025-64104 7.3 langgraph-checkpoint-sqlite: SQL Injection exposes database
Same package: langgraph CVE-2026-28277 6.8 langgraph: Deserialization enables RCE
Same package: langgraph CVE-2026-48775 6.8 LangGraph SQLite: deserialization RCE at checkpoint load
Same package: langgraph