LangGraph Agent Server Vulnerability Allows Approval Bypass via State Mutation

Vulnerability Mechanism

The 'Loopjacking' attack exploits a gap in how LangGraph Agent Server binds human approvals to specific tool calls. In a controlled test, an attacker (acting as a 'Maker') submitted a benign task (e.g., a $20 wire transfer) which triggered a human-in-the-loop interrupt. While the task was in a TASK_STATE_AUTH_REQUIRED state, the attacker used a LangGraph-specific message.command.update message to change the task's arguments to a malicious action (e.g., a $2,000 transfer to an attacker-controlled account). When the human approver subsequently submitted their approval, the system reconstructed the tool call based on the current (mutated) task state rather than the approved state, executing the unauthorized action. The source emphasizes that message.command.update is an Agent Server command, not a general A2A approval primitive.

Affected Versions and Scope

• Affected Software: LangGraph Agent Server.
• Evidence: A hash-verified scan of 131 stable wheels found the relevant forwarding path present in 130 releases from 0.7.5 through 0.13.4. However, the source notes these are source evidence, not runtime demonstrations. Runtime tests confirmed vulnerability in 12 sampled versions, including 0.14.0. Version 0.7.4 was unaffected as the relevant code path did not exist.
• Protocol Context: Prior to A2A specification update PR #2081 (merged July 30, 2026), the spec did not explicitly assign responsibility for defining approval scope, leaving implementation ambiguity. The source clarifies this is a specification clarity gap, not a core A2A protocol vulnerability.

Mitigation and Fixes

The A2A specification has been updated (Section 7.6.4) to clarify that AUTH_REQUIRED is merely a coordination state, not a binding approval. The source recommends developers implement:

• Action-Bound Approvals: Store a hash of the canonical operation (tool name, arguments, principals) at the time of approval.
• Execution-Time Verification: Compare the stored hash against the current operation immediately before dispatch. Reject if mismatched.
• Immutable Dispatch Queues: Enqueue the resolved, immutable operation upon approval, ensuring the dispatcher executes only the queued item, not the mutable task state.
• Policy Controls: Reject command.update messages from unauthorized roles (e.g., 'Maker') while a task is pending approval. The source notes that a supported Auth policy denying maker updates during approval successfully blocked the attack in tests.