CVE-2026-55236: langgraph-api · Incomplete assistant authorization in LangGraph Server run creation
Affects langgraph-apiSource GCVE Database
Not known to be exploited · CVSS 5.9 Medium : upgrade to 0.10.0 when convenient.
Data as of 28 Oct 2026, 22:12 UTC
- Patch
- Available – fixed in 0.10.0
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:NExploitation evidence
Disclosed: evidence found.
CVE published 14 Sep 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 26 Oct 2026.
What to do
Upgrade langgraph-api to 0.10.0.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| PyPIlanggraph-api | Affected
| Fixed in
|
Check your own hosts for these packages with threat-finder (opens in a new tab), our free open-source scanner.
Description
## 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.
References
- github.com/langchain-ai/helm/security/advisories/GHSA-jfj5-wrj9-63x4 (opens in a new tab)
- nvd.nist.gov/vuln/detail/CVE-2026-55236 (opens in a new tab)
- github.com/langchain-ai/docs/blob/7b70fbacab21f84d9c6f9848f86cdeb471adbb50/src/langsmith/agent-server-changelog.mdx (opens in a new tab)
- github.com/langchain-ai/helm (opens in a new tab)
- github.com/pypa/advisory-database/tree/main/vulns/langgraph-api/PYSEC-2026-3858.yaml (opens in a new tab)