CVE-2026-55236: LangGraph authz bypass leaks

Q: Is CVE-2026-55236 actively exploited?

No confirmed active exploitation of CVE-2026-55236 has been reported, but organizations should still patch proactively.

Q: 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.

Q: 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.

Q: What is the CVSS score for CVE-2026-55236?

CVE-2026-55236 has a CVSS v3.1 base score of 5.9 (MEDIUM). The EPSS exploitation probability is 0.26%.

CISO Take

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.

Sources:NVDGitHub AdvisoryATLAS

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?

Authenticated Access

Attacker obtains a legitimate but low-privilege account in a multi-tenant LangGraph Server deployment that uses a custom authorization handler covering only assistants.read.

AML.T0012

Target Identification

Attacker identifies or guesses the ID of a private assistant belonging to another tenant.

Authorization Bypass via Run Creation

Attacker submits a run-creation request referencing the victim's assistant ID; the request dispatches assistants.search instead of assistants.read, no handler is consulted, and the owner filter is omitted from the query.

AML.T0084

Configuration Disclosure and Unauthorized Execution

The server returns the victim assistant's metadata, config, and context to the attacker and executes the new run using that assistant's configuration, exposing potentially sensitive settings and credentials.

AML.T0083

Authenticated Access

Attacker obtains a legitimate but low-privilege account in a multi-tenant LangGraph Server deployment that uses a custom authorization handler covering only assistants.read.

AML.T0012

Target Identification

Attacker identifies or guesses the ID of a private assistant belonging to another tenant.

Authorization Bypass via Run Creation

Attacker submits a run-creation request referencing the victim's assistant ID; the request dispatches assistants.search instead of assistants.read, no handler is consulted, and the owner filter is omitted from the query.

AML.T0084

Configuration Disclosure and Unauthorized Execution

The server returns the victim assistant's metadata, config, and context to the attacker and executes the new run using that assistant's configuration, exposing potentially sensitive settings and credentials.

AML.T0083

What systems are affected?

Package	Ecosystem	Vulnerable Range	Patched
LangGraph	pip	< 0.10.0	`0.10.0`
44.2K4.1K dependentsPushed yesterday77% patched~9d to patchFull package profile →

Do you use LangGraph? You're affected.

How severe is it?

CVSS 3.1

5.9 / 10

EPSS

0.3%

chance of exploitation in 30 days

Higher than 17% of all CVEs

Source: EPSS v3 — FIRST.org

Exploitation Status

No known exploitation

Sophistication

Moderate

What is the attack surface?

AVNetwork

ACHigh

PRLow

UINone

SUnchanged

CHigh

ILow

ANone

What should I do?

1 step

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 does CISA's SSVC say?

DecisionTrack

Exploitationnone

AutomatableNo

Technical Impactpartial

Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.

How is it classified?

Auth BypassData LeakageFrameworkAgentAPIAML.T0083- Credentials from AI Agent Configuration AML.T0084- Discover AI Agent Configuration

Which compliance frameworks are affected?

This CVE is relevant to:

EU AI Act

Article 15-Accuracy, robustness and cybersecurity

ISO 42001

A.6.2-AI system operational planning and access control

NIST AI RMF

MEASURE 2.7-AI system security and resilience is evaluated

OWASP LLM Top 10

LLM02-Sensitive Information Disclosure

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). The EPSS exploitation probability is 0.26%.

What is the AI security impact?

Affected AI Architectures

agent frameworksmulti-tenant SaaS agent platformsauthorization/access control layers

MITRE ATLAS Techniques

AML.T0083Credentials from AI Agent Configuration

AML.T0084Discover AI Agent Configuration

Compliance Controls Affected

EU AI Act: Article 15

ISO 42001: A.6.2

NIST AI RMF: MEASURE 2.7

OWASP LLM Top 10: LLM02

What are the technical details?

Original Advisory

langgraph-api implements the LangGraph API for rapid development and testing. Prior to 0.10.0, the langgraph-api run-creation path authorizes the assistant attached to a run by dispatching assistants.search with an incomplete value instead of the assistants.read event used by direct reads and cron creation. In deployments with custom resource handlers that register only assistants.read, omit an assistants.search handler, and have no global fallback handler, no applicable handler supplies an owner filter, allowing a low-privileged user to reference another user's private assistant through POST /runs or POST /threads/{thread_id}/runs. The run-creation response can disclose the private assistant's metadata, config, and context, and the run can execute using that assistant's configuration. Deployments without custom authorization handlers, or with an equivalent owner filter applied through a global handler or across all assistant events, are not affected. This issue is fixed in version 0.10.0.

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-285Improper AuthorizationPrimary CWE-285Improper Authorization CWE-285Improper Authorization

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.