Description

langgraph-api implements the LangGraph API for rapid development and testing. Prior to 0.10.0, langgraph-api permits a run or cron to specify a relative webhook target that is delivered through an in-process loopback transport, and the authentication middleware treats that transport as internal without applying the authentication context used for external requests. In deployments that rely on per-user authorization to separate threads and runs, an authenticated user can direct a webhook to the server's own thread and run routes, allowing creation of a run on or modification of another user's thread and limited incorporation of the targeted thread's metadata into the created run record. The affected path requires webhook targets and per-user authorization boundaries; deployments that deliberately re-enable loopback delivery should restrict it to controlled same-process routes because those webhooks remain unauthenticated. 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.513Z",
  "pubdate": "2026-09-14T16:17:12.513Z",
  "executiveSummary": "The langgraph-api, prior to version 0.10.0, contains an authentication bypass vulnerability involving the handling of webhook targets. This issue stems from the improper validation of internal loopback transport requests, where the authentication middleware incorrectly classifies these as trusted internal traffic.\nThis vulnerability allows an authenticated attacker to perform unauthorized actions across multi-tenant boundaries. By manipulating webhook targets to point toward internal API routes, an attacker can bypass per-user authorization checks. The impact includes the unauthorized creation or modification of runs on another user's threads and the potential exfiltration of limited thread metadata.\nThe vulnerability affects deployments utilizing per-user authorization boundaries. Exploitation requires the attacker to be authenticated within the system, but it effectively circumvents the logic intended to isolate resource access between different users. The flaw exists due to an trust-by-default configuration for in-process loopback transports, allowing requests to masquerade as system-internal operations.\nOrganizations relying on langgraph-api for multi-user environments are at risk of data integrity compromise and unauthorized state changes. Mitigation necessitates upgrading to version 0.10.0 or higher, which addresses the incorrect classification of loopback transport traffic.",
  "technicalDetails": "The root cause of the vulnerability lies in the design of the authentication middleware within langgraph-api versions prior to 0.10.0. The system permits runs or crons to specify webhook targets; however, when these targets utilize the in-process loopback transport, the middleware misidentifies them as internal-system traffic. This misidentification causes the middleware to bypass the authentication context and per-user authorization checks that are otherwise strictly enforced for external network requests.\nIn a multi-tenant or multi-user environment, these authorization checks are the primary defensive mechanism ensuring that a user can only interact with threads and runs they own or have explicit permission to access. By specifying a relative URL for a webhook target that points to the API's own internal routing for thread or run management, an attacker can coerce the server into processing the request as an authenticated internal operation rather than a user-originated action.\nThe attack flow proceeds as follows: First, an authenticated attacker initiates a request (such as a run or cron creation) containing a specifically crafted webhook target URI. This URI is designed to target internal paths, such as endpoints responsible for creating, updating, or modifying thread data. Second, the langgraph-api engine processes the webhook delivery via the loopback transport. Third, the authentication middleware intercepts the request but incorrectly trusts the loopback source, granting it full privileges without validating the original user context. Finally, the application executes the requested operation—such as creating a run on a target user's thread—against the victim's resource, effectively bypassing the intended isolation boundary.\nThe vulnerability is particularly critical because it allows for the manipulation of system state across user boundaries. While the delivery is restricted to the internal loopback transport, the lack of authentication ensures that the API endpoints reachable via this transport are exposed to the malicious actions of any authenticated user. If a deployment is forced to re-enable this loopback delivery for legitimate purposes, it remains inherently vulnerable unless the transport is strictly restricted to controlled, safe routes that do not accept sensitive input or perform state-changing operations. Post-exploitation, an attacker could potentially integrate targeted thread metadata into their own controlled records, leading to unauthorized information disclosure regarding the victim's workflows or data structures."
}