CVE-2026-55235 in langgraph-api
Summary
by MITRE • 09/14/2026
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.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 09/14/2026
The vulnerability identified within langgraph-api prior to version 0.10.0 represents a critical authentication bypass and authorization flaw rooted in the handling of internal versus external network traffic. The application implements an API for rapid development and testing, which includes functionality allowing users to initiate runs or configure cron jobs with webhook targets. A significant architectural oversight exists in how the system distinguishes between requests originating from outside the server and those generated internally via a loopback transport mechanism. Specifically, when a run or cron job specifies a relative webhook target, the request is delivered through an in-process loopback path rather than traversing the external network interface. The authentication middleware within langgraph-api incorrectly classifies this internal loopback traffic as trusted internal communication. Consequently, it bypasses the standard authentication context and security checks that are strictly applied to all external requests. This design decision creates a fundamental trust boundary violation where code executing inside the application process is granted privileges equivalent to an unauthenticated actor or one with elevated permissions depending on how the middleware interprets local traffic.
This technical flaw leads directly to severe operational impacts regarding data integrity and user isolation, particularly in deployments that rely on per-user authorization models to separate threads and runs among different users. Because the loopback transport is treated as internal without applying authentication context, an authenticated user can exploit this mechanism to direct a webhook target back to the server's own thread and run routes. By manipulating these relative targets, the attacker effectively tricks the application into processing actions on behalf of other users or system processes that should not be accessible via this specific code path. The primary consequence is the ability for an authenticated malicious user to create runs within another user’s thread or modify existing threads belonging to others. This constitutes a clear violation of multi-tenancy isolation principles, allowing lateral movement across logical boundaries defined by user identity rather than network location.
The scope of damage extends beyond simple access control violations into potential data contamination and metadata manipulation. The vulnerability allows the attacker not only to create runs or modify thread structures but also facilitates the limited incorporation of targeted threads' metadata into newly created run records associated with the attacker’s context. This means that sensitive information, configuration details, or execution history belonging to other users can be exfiltrated indirectly through the structure and content of these manipulated runs. In environments where langgraph-api is used for critical workflow automation or data processing pipelines, this could lead to corrupted state, unauthorized access to proprietary logic defined in threads, or further exploitation vectors if downstream systems trust metadata propagated from these compromised run records. The impact is particularly acute because it leverages legitimate application functionality—webhook delivery and cron scheduling—to achieve malicious ends without triggering typical intrusion detection signals associated with external attacks.
From a classification perspective, this vulnerability aligns closely with CWE-287 Improper Authentication, as the system fails to properly verify identity when handling internal requests that should require strict validation. It also maps significantly to CWE-862 Missing Authorization, since authenticated users are able to perform actions on resources belonging to other users due to a failure in enforcing access control policies for specific code paths. In terms of offensive security frameworks such as MITRE ATT&CK, this behavior is consistent with techniques involving privilege escalation or lateral movement within an application environment, specifically leveraging internal service communication channels that lack proper integrity checks. The flaw highlights the danger of assuming local loopback traffic is inherently safe; modern secure development practices dictate that even in-process calls must respect security contexts unless explicitly and securely isolated by design patterns like zero-trust microservices with mutual TLS or strict API gateway enforcement for all entry points, including internal ones.
To mitigate this vulnerability, organizations running langgraph-api versions prior to 0.10.0 should immediately upgrade to version 0.10.0 where the issue has been resolved by correcting the authentication middleware logic. For deployments that cannot update immediately or those with specific architectural requirements for loopback delivery, it is imperative to restrict such internal webhook targets strictly to controlled same-process routes that do not intersect with user-facing thread and run APIs. Developers must ensure that any component handling internal requests explicitly applies the same rigorous authentication and authorization checks as external endpoints unless a formally documented security exception exists with compensating controls. Furthermore, auditing existing code for similar patterns where relative URLs or local redirects bypass middleware is recommended to prevent analogous flaws in other parts of the application stack. Ensuring that per-user isolation boundaries are enforced regardless of the request origin path is essential for maintaining data confidentiality and integrity in multi-tenant SaaS environments utilizing this framework.