Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
LangGraph deployments using JavaScript or TypeScript custom authentication may fail to apply Store authorization changes returned by an authorization handler. In affected deployments, an authenticated user may be able to access Store data outside their authorized namespace. Required conditions A deployment is affected only when all of the following conditions apply: - It uses an affected `langgraph-api` version. - It runs JavaScript or TypeScript custom authentication. - Its Store authorization handler relies on rewriting the requested namespace to restrict each user to their own data. - The attacker can authenticate as an ordinary user. - Multiple users' data is stored through the affected authorization path. Python custom authentication handlers are not affected. JavaScript or TypeScript handlers that reject unauthorized namespace requests instead of rewriting them are also not affected. The attack does not require administrator privileges, user interaction, a race…
Recommended action: Upgrade to 0.15.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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…
Recommended action: Upgrade to 0.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In affected versions of `langgraph-api` (the LangGraph Server runtime), a run or cron could be created with a relative webhook target. When the server later delivers such a webhook, it routes the request back into the same application through an in-process loopback transport that the authentication middleware treats as internal and does not authenticate. As a result, a relative webhook target could reach the server's own routes that operate on threads and runs without the authentication context that applies to ordinary external requests. In deployments that scope threads and runs by owner, this could allow a request associated with one user to reach routes operating on another user's thread, resulting in creation of a run on (or modification of the state of) a thread owned by another user, even where the corresponding direct external requests were correctly denied. Limited metadata from the targeted thread may be incorporated into the created run record. We have no…
Recommended action: Upgrade to 0.10.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.