Live › vulnerability › CVE-2026-55236
Go to dashboardlanggraph-api (the LangGraph Server runtime) used a different authorization event on run creation than on other assistant paths, so custom handlers that only registered assistants.read left the owner filter empty. An authenticated user could create a run against another user's private assistant and receive that assistant's metadata, config and context in the response.
Summary written from the sources below. Check the originals before acting.
First seen by InfraStack 2026-10-28 21:12 UTC, 0h before NVD. All times on this page are UTC.
Deployments running langgraph-api below 0.10.0 that use custom authorization handlers gating assistant access through assistants.read or assistants.search rather than a global handler. Deployments without custom authorization handlers, or whose handlers apply an owner filter across all assistant events, are not affected. Look at the LangGraph Server and Agent Server runtime, including installs through the LangGraph Platform Helm chart.
| Product | Ecosystem | Affected | Fixed in |
|---|---|---|---|
| langgraph-api | pypi | < 0.10.0 | 0.10.0 |
pip show langgraph-api and confirm the version is below 0.10.0assistants.read and assistants.search registrations; if there is no assistants.search handler and no global handler, you are in the affected configurationlanggraph-api to 0.10.0 or laterassistants.read handler (or a global handler covering it) that returns an owner-style filter, and confirm parity across assistant read, search, and run/cron creationEach row is the first time that source carried this signal. The analyst’s rows are its own findings.
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.
You may be affected if you:
langgraph-api (the LangGraph Server / Agent Server runtime, including via the LangGraph Platform Helm chart), andassistants.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.
metadata, config, and context through the run-creation response. These fields can contain sensitive configuration.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:
assistants.search during run creation are no longer consulted on that path; provide an equivalent assistants.read handler that returns the same owner filter.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.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.This page as .md · .json · in your agent: get_signal("CVE-2026-55236")
GitHub Advisory Database, CC-BY 4.0 · NVD data is provided by NIST and is public domain. Posts quoted belong to their authors.