CVE-2026-55236: Medium severity pip/langgraph-api vulnerability
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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
pip/langgraph-apito a version that resolves this vulnerability.Fixed in 0.10.0 - Upgrade
Upgrade
langgraph-apito a version that resolves this vulnerability.Fixed in 0.10.0 - Configuration
Register an `assistants.read` authorization handler (or a global handler covering it) that returns the same owner-style filter used for direct assistant access, and confirm parity across assistant read, assistant search, and run/cron creation paths. (The run/cron creation path now dispatches `assistants.read` in both in-memory and gRPC/Postgres runtimes.)
LangGraph authorization handlers assistants.read handler (or global handler covering assistants.read) = owner-style filter - Configuration
If you use custom authorization handlers, ensure your assistant access gating logic applies an equivalent owner filter across both `assistants.search` and `assistants.read` (or use a global handler covering all assistant events). This is to avoid gaps where run-creation previously consulted a different authorization event and omitted the owner constraint.
LangGraph authorization handlers assistants.search handler for run-creation authorization = ensure parity with assistants.read owner filter - Configuration
Because the `metadata` field on the `assistants.read` event during run and cron creation is no longer populated, update any handlers that read/stamp `metadata` so that the logic is moved into the run/cron create handlers (where client-supplied run/cron metadata is consistently shaped and used).
LangGraph authorization handlers / run & cron create handlers metadata handling during authorization events = do not rely on assistants.read metadata stamping; move logic into run/cron create handlers
Event History
Frequently Asked Questions
Which deployments are affected?
The issue affects deployments with custom authorization handlers that register assistants.read but do not register assistants.search and do not provide a global fallback handler. In that configuration, run creation can bypass the owner constraint that would normally restrict access to another user's private assistant.
What must an attacker be able to do?
An attacker needs the ability to submit a request to create a run and reference a private assistant owned by another user. The attacker must also be able to identify or supply the referenced assistant.
What information could be exposed through a successful run-creation request?
The response can merge the referenced assistant's metadata, config, and context into fields returned to the requester. Those fields may contain sensitive configuration and are encrypted at rest by the runtime.
How can administrators determine whether their authorization setup is exposed?
Review custom authorization handler registration for assistant events. The vulnerable condition exists when assistants.read is handled but assistants.search is not handled and no global fallback handler is available.