GHSA-jfj5-wrj9-63x4 — langgraph-api
MEDIUMGHSA-jfj5-wrj9-63x4 is a medium-severity (CVSS 5.9) CWE-285 vulnerability in langgraph-api. A fix is available for langgraph-api — see the affected versions and patch details below.
langgraph-api: Incomplete assistant authorization in LangGraph Server run creation
Exploitation Status
No confirmed exploitation observed yet
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-jfj5-wrj9-63x4.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
How urgent is this, really
GHSA-jfj5-wrj9-63x4 by exploitation likelihood (EPSS) against impact (CVSS). Outside the shaded patch-first corner.
Where this sits among everything scored
Of 382,621 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Counts from FIRST.org, log-scaled.
Real-World Exposure
langgraph-apiReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects PyPI packages — download data is not available via public APIs for these ecosystems.
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.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐍PyPI | langgraph-api | all versions | 0.10.0pip install --upgrade 'langgraph-api==0.10.0' |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for langgraph-api, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update langgraph-api to 0.10.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-jfj5-wrj9-63x4 is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
Frequently Asked Questions
Is GHSA-jfj5-wrj9-63x4 in your dependencies?
Find it across PyPI, including transitive dependencies.