CVE-2026-55236: langgraph-api Incomplete Assistant Authorization Vulnerability

MODERATE
Advisory Identifier: GHSA-jfj5-wrj9-63x4
CVSS 5.9
CWE-285
Published
Advisory Summary

CVE-2026-55236 is a MODERATE (CVSS 5.9) incomplete assistant authorization vulnerability (CWE-285: Improper Authorization) affecting langgraph-api libraries in the PyPI ecosystem. The issue involves incomplete assistant authorization in langgraph server run creation. Remediation is available by upgrading affected packages to version 0.10.0.

CVE-2026-55236 at a Glance

CVE Identifier CVE-2026-55236
GHSA Identifier GHSA-jfj5-wrj9-63x4
Severity MODERATE
CVSS v3.1 Base Score 5.9
CWE Classification CWE-285: Improper Authorization
Affected Product langgraph-api
Package Ecosystem PyPI
Published Date
Last Updated

Security Impact

CVSS: 5.9

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N).

Attack Vector Network (AV:N)
Attack Complexity High (AC:H)
Privileges Required Low (PR:L)
User Interaction None (UI:N)
Scope Unchanged (S:U)
Confidentiality High (C:H)
Integrity Low (I:L)
Availability None (A:N)

How to Fix CVE-2026-55236

To remediate this vulnerability, upgrade all affected langgraph-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.

langgraph-api fixed: 0.10.0
pip install langgraph-api>=0.10.0
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 langgraph-api

How to Check if You Are Affected

To determine whether your Python environment is affected by CVE-2026-55236, inspect your installed packages using pip:

pip show langgraph-api

Analyze the terminal output to locate any version of langgraph-api in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 0.10.0), your application is affected.

Note: The pip show langgraph-api command checks currently installed packages in your active Python environment.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-285: Improper Authorization, where the product does not perform or incorrectly performs an authorization check when an actor attempts to access a resource or perform an action. In langgraph-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

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

CVE-2026-55236 Affected langgraph-api Versions

1 component(s)
Fixed Versions:
0.10.0
Product / Package Ecosystem Affected Versions Fixed Version
langgraph-api
PyPI
< 0.10.0
0.10.0

References

Frequently Asked Questions

What is CVE-2026-55236?
CVE-2026-55236 is a security vulnerability in langgraph-api involving Incomplete assistant authorization in LangGraph Server run creation under CWE-285: Improper Authorization.
Which langgraph-api versions are affected?
Affected versions include releases prior to 0.10.0 across affected packages: langgraph-api.
What version fixes CVE-2026-55236?
Upgrading to 0.10.0 (or the latest patched release for your respective branch) resolves the vulnerability.
Is langgraph-api affected?
Yes, langgraph-api is affected in releases prior to 0.10.0. Upgrade your dependency to 0.10.0 or later.
What is the CVSS score of CVE-2026-55236?
CVE-2026-55236 has a CVSS v3.1 base score of 5.9 (MODERATE) with vector string CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N.
What CWE is associated with CVE-2026-55236?
CVE-2026-55236 is classified under 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.).
How can I check PyPI dependencies for CVE-2026-55236?
Run the dependency tree command: 'pip show langgraph-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-jfj5-wrj9-63x4",
  "modified" : "2026-08-19T18:56:03Z",
  "published" : "2026-08-19T18:56:03Z",
  "aliases" : [ "CVE-2026-55236" ],
  "summary" : "langgraph-api: Incomplete assistant authorization in LangGraph Server run creation",
  "details" : "## Summary\n\nIn 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.\n\nAs 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.\n\nWe have no evidence of this behavior occurring in the wild.\n\n## Affected users / systems\n\nYou may be affected if you:\n\n- run `langgraph-api` (the LangGraph Server / Agent Server runtime, including via the LangGraph Platform Helm chart), and\n- 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.\n\nDeployments 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.\n\n## Impact\n\n- Confidentiality: exposure of another user's private assistant `metadata`, `config`, and `context` through the run-creation response. These fields can contain sensitive configuration.\n- 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.\n\n## Patches / mitigation\n\nRun 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.\n\nThis is a behavioral change for deployments with custom authorization handlers:\n\n- 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.\n- 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.\n\n## Operational guidance\n\n- 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.\n- Upgrade to a release containing this change.",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "PyPI",
      "name" : "langgraph-api"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "0.10.0"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/langchain-ai/helm/security/advisories/GHSA-jfj5-wrj9-63x4"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/langchain-ai/helm"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-285" ],
    "severity" : "MODERATE",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-08-19T18:56:03Z",
    "nvd_published_at" : null
  }
}