GHSA-JFJ5-WRJ9-63X4
Vulnerability from github – Published: 2026-08-19 18:56 – Updated: 2026-08-19 18:56Summary
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.readorassistants.searchhandler 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, andcontextthrough 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.searchduring run creation are no longer consulted on that path; provide an equivalentassistants.readhandler that returns the same owner filter. - The metadata field on the
assistants.readevent 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.readhandler (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.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "langgraph-api"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.10.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55236"
],
"database_specific": {
"cwe_ids": [
"CWE-285"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-19T18:56:03Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"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\u0027s `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\u0027s 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\u0027s private assistant, beyond the requesting user\u0027s authorization scope; the run is then carried out using that assistant\u0027s 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.",
"id": "GHSA-jfj5-wrj9-63x4",
"modified": "2026-08-19T18:56:03Z",
"published": "2026-08-19T18:56:03Z",
"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"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "langgraph-api: Incomplete assistant authorization in LangGraph Server run creation"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.