langgraph-api: Incomplete assistant authorization in LangGraph Server run creation
Impact
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…
Source excerpt · OSVAffected packages
Start with the recorded fix for your release branch. Check your installed version and test compatibility before upgrading. Fixing this advisory does not rule out other vulnerabilities in the release.
| Affected range | Recorded fix |
|---|---|
| Earlier releases before 0.10.0Ecosystem versions | 0.10.0 |
Version evidence: OSV · GHSA-jfj5-wrj9-63x4
View original version evidence (410 explicit versions)
Original source 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.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.
Inside the record
Evidence available
Describes the evidence in this view, not whether the product is safe.
Original records
CVE-2026-55236View the latest unmodified CVE JSON from the official source. It may be newer than this imported page.
cve.new JSON →What changed
Follow changesLarge field values are marked as truncated previews. Original source snapshots remain retained.