https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 28 Sep 2026 15:31:49 +0000 https://vulnerability.circl.lu/vuln/cve-2026-55236 <p><strong>Affected:</strong> langchain-ai langgraph-api</p> <p>langgraph-api implements the LangGraph API for rapid development and testing. Prior to 0.10.0, the langgraph-api run-creation path authorizes the assistant attached to a run by dispatching assistants.search with an incomplete value instead of the assistants.read event used by direct reads and cron creation. In deployments with custom resource handlers that register only assistants.read, omit an assistants.search handler, and have no global fallback handler, no applicable handler supplies an owner filter, allowing a low-privileged user to reference another user&#39;s private assistant through POST /runs or POST /threads/{thread_id}/runs. The run-creation response can disclose the private assistant&#39;s metadata, config, and context, and the run can execute using that assistant&#39;s configuration. Deployments without custom authorization handlers, or with an equivalent owner filter applied through a global handler or across all assistant events, are not affected. This issue is fixed in version 0.10.0.</p> <p><strong>Affected:</strong> langchain-ai langgraph-api</p> <p>langgraph-api implements the LangGraph API for rapid development and testing. Prior to 0.10.0, the langgraph-api run-creation path authorizes the assistant attached to a run by dispatching assistants.search with an incomplete value instead of the assistants.read event used by direct reads and cron creation. In deployments with custom resource handlers that register only assistants.read, omit an assistants.search handler, and have no global fallback handler, no applicable handler supplies an owner filter, allowing a low-privileged user to reference another user&#39;s private assistant through POST /runs or POST /threads/{thread_id}/runs. The run-creation response can disclose the private assistant&#39;s metadata, config, and context, and the run can execute using that assistant&#39;s configuration. Deployments without custom authorization handlers, or with an equivalent owner filter applied through a global handler or across all assistant events, are not affected. This issue is fixed in version 0.10.0.</p> https://vulnerability.circl.lu/vuln/cve-2026-55236 https://vulnerability.circl.lu/vuln/ghsa-jfj5-wrj9-63x4 <p><strong>Affected:</strong> PyPI: langgraph-api</p> <p>## Summary</p> <p>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.</p> <p>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&#39;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.</p> <p>We have no evidence of this behavior occurring in the wild.</p> <p>## Affected users / systems</p> <p>You may be affected if you:</p> <p>- run `langgraph-api` (the LangGraph Server / Agent Server runtime, including via the LangGraph Platform Helm chart), and - use custom authorization handlers that gate assistant…</p> <p><strong>Affected:</strong> PyPI: langgraph-api</p> <p>## Summary</p> <p>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.</p> <p>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&#39;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.</p> <p>We have no evidence of this behavior occurring in the wild.</p> <p>## Affected users / systems</p> <p>You may be affected if you:</p> <p>- run `langgraph-api` (the LangGraph Server / Agent Server runtime, including via the LangGraph Platform Helm chart), and - use custom authorization handlers that gate assistant…</p> https://vulnerability.circl.lu/vuln/ghsa-jfj5-wrj9-63x4