Description

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's private assistant through POST /runs or POST /threads/{thread_id}/runs. The run-creation response can disclose the private assistant's metadata, config, and context, and the run can execute using that assistant'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.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "5.9",
  "pubDate": "2026-09-14T16:17:12.663Z",
  "pubdate": "2026-09-14T16:17:12.663Z",
  "executiveSummary": "A broken access control vulnerability exists in langgraph-api versions prior to 0.10.0, specifically within the run-creation path for assistants.\nThe vulnerability occurs because the system utilizes an incomplete assistants.search event for authorization instead of the expected assistants.read event.\nThis flaw allows low-privileged, authenticated users to reference and execute runs using private assistants belonging to other users, leading to unauthorized data disclosure and resource consumption.\nThe risk is particularly high in deployments utilizing custom resource handlers that do not include an assistants.search handler or a global authorization fallback.\nSuccessful exploitation allows an attacker to access private assistant metadata, configuration, and context, effectively bypassing intended tenant isolation.",
  "technicalDetails": "The root cause of this vulnerability lies in an authorization logic inconsistency within the langgraph-api run-creation workflow. When a request is made to POST /runs or POST /threads/{thread_id}/runs, the application attempts to authorize the associated assistant. Instead of invoking the secure assistants.read event used for direct resource access and cron-based operations, the system dispatches an assistants.search event with insufficient filter parameters.\nIn environments where custom resource handlers are implemented, developers may have explicitly registered assistants.read to enforce ownership checks but omitted an assistants.search handler. Without a global authorization fallback to enforce ownership filtering on all events, the search operation returns private assistant objects that should otherwise be inaccessible to the requester.\nThe exploitation flow proceeds as follows: An attacker identifies an assistant ID associated with a target user. The attacker initiates a run creation request (POST /runs or POST /threads/{thread_id}/runs) referencing the target's private assistant ID in the payload. Because the backend utilizes the assistants.search event for authorization, and because the search handler lacks an 'owner' filter in the absence of a specific custom implementation, the backend fails to validate that the requesting user owns the requested assistant. Consequently, the API treats the unauthorized assistant as valid.\nThe impact of this exploitation is twofold. First, the run-creation API response may disclose sensitive assistant metadata, system configurations, and interaction contexts that were intended to be private. Second, the run is successfully initialized and executed using the victim's assistant configuration, leading to potential unauthorized usage of external tools, model inference cycles, and data processing as defined in the target assistant's setup.\nDeployments are only vulnerable if they rely on custom resource handlers that fail to define uniform authorization across both assistants.read and assistants.search events, or if they lack a global middleware that enforces an owner filter universally. Versions 0.10.0 and above remediate this by correcting the event dispatching logic."
}