GHSA-jfj5-wrj9-63x4: 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 that covers `assistants.read`) that returns an owner-style filter, and confirm parity across assistant read, assistant search, and run/cron creation paths. This addresses the run-creation path behavior where only `assistants.search` gating was previously consulted.
LangGraph authorization handlers assistants.read vs assistants.search registration = Ensure an assistants.read handler (or a global handler covering it) that returns an owner-style filter is registered; do not rely on assistants.search-only during run creation authorization - Configuration
Update custom authorization handlers that read or stamp the `metadata` field for `assistants.read` during run/cron creation: the `metadata` field is no longer populated on that event during run and cron creation. If your logic depends on it, relocate that logic into the run/cron create handlers.
LangGraph authorization handlers metadata handling during assistants.read = Move logic that reads/stamps the `metadata` field out of assistants.read during run/cron creation (since it is no longer populated there) and into the run/cron create handlers - Compensating control
If you have custom authorization handlers that gate assistant access, ensure they gate access via `assistants.read` (or an equivalent global handler covering it) rather than relying on a global handler covering all assistant events without the correct owner-style filter.
Event History
Frequently Asked Questions
Which deployments are affected by this authorization bypass?
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 may omit the owner constraint when resolving an assistant.
What does an attacker need to exploit the issue?
An attacker needs the ability to create a run and must reference a private assistant owned by another user. No user interaction is required, but successful exploitation depends on the affected custom authorization-handler configuration.
What information could be exposed through a malicious run-creation request?
The run-creation response can return the referenced assistant's metadata, config, and context. These fields may contain sensitive configuration and are encrypted at rest by the runtime.
How can I determine whether my deployment is vulnerable?
Review custom authorization-handler registration for assistant-related events. A deployment is in the described affected state if it handles assistants.read but has no assistants.search handler and no global fallback handler.
What mitigation is available if patching cannot be done immediately?
Configure an assistants.search authorization handler or a global fallback handler so that the run-creation path receives an authorization decision. Ensure that the handler enforces the expected owner constraint for private assistants.