AI Threat AlertA flaw in langgraph-api (the LangGraph Server runtime that underpins many production AI agent deployments) lets a webhook target set to a relative or loopback URL route back into the server's own API through an internal transport that the authentication middleware never checks, because it treats loopback traffic as trusted. In multi-tenant deployments that authorize threads and runs per owner, this lets one user's webhook reach another user's thread routes and create a run on it or alter its state, with limited thread metadata bleeding into the attacker-visible run record — even though the same request made directly from outside would have been correctly denied. With 3,763 downstream dependents, the blast radius spans a meaningful share of production LangGraph deployments, though there's no EPSS score, no CISA KEV listing, and no public exploit or Nuclei template, so this reads as a real but currently unweaponized multi-tenant integrity issue rather than an active threat. Patch to langgraph-api 0.10.0 or later, where `webhooks.url.disable_loopback` now defaults to enabled; if you've explicitly re-enabled loopback delivery, confirm the routes it reaches enforce their own authorization, and audit run/cron records for webhook targets pointing at relative paths or loopback-resolving hostnames as a detection signal.
What is the risk?
CVSS 5.9 (medium) reflects high attack complexity (AC:H) and the requirement for low privileges (PR:L) — an attacker needs an authenticated account on the same LangGraph Server instance and must understand the loopback webhook delivery mechanism, which isn't obvious from the public API surface. There's no evidence of in-the-wild exploitation, no EPSS score published, it's absent from CISA KEV, and no public PoC or scanner template exists, so near-term opportunistic exploitation is unlikely. The real risk is concentrated in multi-tenant SaaS or shared-platform deployments of LangGraph Server where tenant isolation is a compliance or contractual requirement — there, even a single successful cross-tenant run creation is a material integrity and confidentiality finding, not just a technical curiosity.
How does the attack unfold?
What systems are affected?
| Package | Ecosystem | Vulnerable Range | Patched |
|---|---|---|---|
| LangGraph | pip | < 0.10.0 | 0.10.0 |
Do you use LangGraph? You're affected.
How severe is it?
What is the attack surface?
What should I do?
1 stepUpgrade to langgraph-api 0.10.0 or later, which flips
webhooks.url.disable_loopbackto enabled by default, blocking relative webhook targets, localhost-style hostnames, loopback address ranges, and hostnames that resolve into the loopback range. If your deployment legitimately needs loopback webhook delivery (e.g., internal same-process callbacks), only re-enable it viawebhooks.url.disable_loopback: falseinlanggraph.json(orLANGGRAPH_WEBHOOKS) for routes you fully control, and add explicit authorization checks inside those routes since loopback-delivered requests arrive unauthenticated. For detection, audit existing run and cron records for webhook URLs that are relative paths,localhost/127.0.0.1/::1, or hostnames resolving into loopback ranges, and review run creation logs for runs on a thread whose owner doesn't match the API caller that scheduled the originating webhook.
What does CISA's SSVC say?
Source: CISA Vulnrichment (SSVC v2.0). Decision based on the CISA Coordinator decision tree.
How is it classified?
Which compliance frameworks are affected?
This CVE is relevant to:
Frequently Asked Questions
What is CVE-2026-55235?
A flaw in langgraph-api (the LangGraph Server runtime that underpins many production AI agent deployments) lets a webhook target set to a relative or loopback URL route back into the server's own API through an internal transport that the authentication middleware never checks, because it treats loopback traffic as trusted. In multi-tenant deployments that authorize threads and runs per owner, this lets one user's webhook reach another user's thread routes and create a run on it or alter its state, with limited thread metadata bleeding into the attacker-visible run record — even though the same request made directly from outside would have been correctly denied. With 3,763 downstream dependents, the blast radius spans a meaningful share of production LangGraph deployments, though there's no EPSS score, no CISA KEV listing, and no public exploit or Nuclei template, so this reads as a real but currently unweaponized multi-tenant integrity issue rather than an active threat. Patch to langgraph-api 0.10.0 or later, where `webhooks.url.disable_loopback` now defaults to enabled; if you've explicitly re-enabled loopback delivery, confirm the routes it reaches enforce their own authorization, and audit run/cron records for webhook targets pointing at relative paths or loopback-resolving hostnames as a detection signal.
Is CVE-2026-55235 actively exploited?
No confirmed active exploitation of CVE-2026-55235 has been reported, but organizations should still patch proactively.
How to fix CVE-2026-55235?
Upgrade to langgraph-api 0.10.0 or later, which flips `webhooks.url.disable_loopback` to enabled by default, blocking relative webhook targets, localhost-style hostnames, loopback address ranges, and hostnames that resolve into the loopback range. If your deployment legitimately needs loopback webhook delivery (e.g., internal same-process callbacks), only re-enable it via `webhooks.url.disable_loopback: false` in `langgraph.json` (or `LANGGRAPH_WEBHOOKS`) for routes you fully control, and add explicit authorization checks inside those routes since loopback-delivered requests arrive unauthenticated. For detection, audit existing run and cron records for webhook URLs that are relative paths, `localhost`/`127.0.0.1`/`::1`, or hostnames resolving into loopback ranges, and review run creation logs for runs on a thread whose owner doesn't match the API caller that scheduled the originating webhook.
What systems are affected by CVE-2026-55235?
This vulnerability affects the following AI/ML architecture patterns: agent frameworks, multi-tenant agent orchestration, webhook/callback pipelines.
What is the CVSS score for CVE-2026-55235?
CVE-2026-55235 has a CVSS v3.1 base score of 5.9 (MEDIUM). The EPSS exploitation probability is 0.36%.
What is the AI security impact?
Affected AI Architectures
MITRE ATLAS Techniques
AML.T0049Exploit Public-Facing ApplicationCompliance Controls Affected
What are the technical details?
Original Advisory
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.
Exploitation Scenario
An attacker with a valid low-privilege account on a shared LangGraph Server instance creates a run or cron job and sets its webhook target to a relative path (or a loopback-resolving hostname) pointing at an internal API route that operates on threads and runs. When the server later fires that webhook, it delivers the callback through its in-process loopback transport, which the authentication middleware implicitly trusts and does not re-authenticate — unlike an equivalent external HTTP request, which the same middleware would correctly reject. Because the delivered request lacks the authorization context tying it to the attacker's own tenant scope, it can land on API routes governing a different user's thread, letting the attacker trigger creation of a new run against that thread (or mutate its state) and capture whatever thread metadata gets echoed back into the resulting run record — all without ever directly querying the victim's thread through a normal, correctly-authorized request.
Weaknesses (CWE)
CWE-287Improper AuthenticationPrimaryCWE-287Improper AuthenticationPrimaryCWE-287Improper AuthenticationCWE-287 — Improper Authentication: When an actor claims to have a given identity, the product does not prove or insufficiently proves that the claim is correct.
- [Architecture and Design] Use an authentication framework or library such as the OWASP ESAPI Authentication feature.
Source: MITRE CWE corpus.
CVSS Vector
CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:H/A:LReferences
Timeline
Related Vulnerabilities
CVE-2026-552537.7LangGraph Mongo: NoSQL injection exposes tenant data
Same package: langgraphCVE-2025-676447.3langgraph-checkpoint-sqlite: SQL Injection exposes database
Same package: langgraphCVE-2025-641047.3langgraph-checkpoint-sqlite: SQL Injection exposes database
Same package: langgraphCVE-2025-87097.3langgraph-checkpoint-sqlite: SQL Injection exposes database
Same package: langgraphCVE-2026-282776.8langgraph: Deserialization enables RCE
Same package: langgraph