---
id: "CVE-2026-55236"
kind: "vulnerability"
aliases: ["CVE-2026-55236", "GHSA-jfj5-wrj9-63x4"]
title: "langgraph-api: Incomplete assistant authorization in LangGraph Server run creation"
severity: "medium"
cvss: 5.9
epss: 0.00255
exploited: false
status: "open"
category: "ai-tooling"
products: [{"name": "langgraph-api", "fixed": ["0.10.0"], "affected": "< 0.10.0", "ecosystem": "pypi"}]
ecosystems: ["pypi"]
tags: ["ai-agents", "ai-tooling", "cwe-285", "kubernetes", "langgraph", "python", "self-hosted"]
not_affected_if: ["default-config", "global-auth-handler", "no-custom-auth-handlers"]
published_at: "2026-08-19T18:56:03+00:00"
first_seen_at: "2026-10-28T21:12:45+00:00"
updated_at: "2026-10-28T21:13:47+00:00"
sources: [{"source": "ghsa", "url": "https://github.com/advisories/GHSA-jfj5-wrj9-63x4", "first_seen_at": "2026-10-28T21:12:45+00:00"}, {"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55236", "first_seen_at": "2026-10-28T21:35:45+00:00"}]
---

# langgraph-api: Incomplete assistant authorization in LangGraph Server run creation

langgraph-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, check and fix written by a model from the sources; labelled as such._

## Affected

- pypi:langgraph-api affected < 0.10.0 fixed 0.10.0

## How to check

- Run `pip show langgraph-api` and confirm the version is below `0.10.0`
- Search your authorization handler code for `assistants.read` and `assistants.search` registrations; if there is no `assistants.search` handler and no global handler, you are in the affected configuration
- Test that a user cannot POST a run referencing another user's private assistant ID

## Fix

- Upgrade `langgraph-api` to `0.10.0` or later
- Register an `assistants.read` handler (or a global handler covering it) that returns an owner-style filter, and confirm parity across assistant read, search, and run/cron creation
- Move any logic that read or stamped the metadata field on the assistants.read event during run and cron creation into the run/cron create handlers

## Timeline

- 2026-10-28T21:12:45+00:00 ghsa https://github.com/advisories/GHSA-jfj5-wrj9-63x4
- 2026-10-28T21:35:45+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-55236

## From the sources

## 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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_