CVE-2026-113707 in a2a-rs
Summary
by MITRE • 10/22/2026
A security flaw has been discovered in a2aproject a2a-rs up to 0.4.4. The affected element is the function InMemoryTaskStore::update of the file a2a-server/src/task_store/inmemory.rs. The manipulation results in race condition. The attack may be performed from remote. The patch is identified as 7050c7d329238539424ee46440e23b91c4825bee. It is advisable to implement a patch to correct this issue.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/22/2026
The vulnerability identified in the a2a-rs project, specifically within versions up to 0.4.4, represents a critical concurrency flaw located in the InMemoryTaskStore::update function found in the file a2a-server/src/task_store/inmemory.rs. This component serves as an in-memory storage mechanism for task states within the A2A server architecture, which is designed to facilitate agent-to-agent communication and coordination. The presence of this vulnerability indicates that the internal state management logic fails to properly synchronize access when multiple threads or asynchronous tasks attempt to modify the same data structure simultaneously. In concurrent programming environments, particularly those utilizing Rust's async runtime, ensuring thread safety for shared mutable state requires explicit synchronization primitives such as mutexes, read-write locks, or atomic operations. The absence of these safeguards in the update function creates a window where race conditions can occur, leading to unpredictable behavior and potential data corruption.
From a technical perspective, this flaw is classified under CWE-362, which denotes concurrent execution using shared resource with improper synchronization. When multiple requests arrive concurrently to update task states, the lack of proper locking mechanisms means that read-modify-write operations may interleave incorrectly. For instance, one thread might read the current state of a task while another thread modifies it simultaneously. This can result in lost updates where changes made by one request are overwritten by stale data from another, or it could lead to inconsistent internal states that violate business logic constraints enforced by the application. In systems relying on accurate task tracking for orchestration workflows, such inconsistencies can cause tasks to be marked as completed prematurely, skipped entirely, or left in a limbo state requiring manual intervention.
The operational impact of this vulnerability is significant due to its remote exploitability. Since the affected function handles updates from incoming requests, an attacker capable of sending concurrent HTTP requests to the A2A server endpoint can trigger these race conditions intentionally. By flooding the service with parallel update commands targeting specific task identifiers, an adversary could manipulate the state machine governing agent tasks. This capability undermines the integrity and reliability of the automation workflows managed by the system. In a production environment handling sensitive or high-value automated processes, such manipulation could lead to data inconsistency across distributed agents, failure in executing critical sequences, or denial of service through resource exhaustion caused by corrupted internal states requiring recovery procedures.
This vulnerability aligns with MITRE ATT&CK technique T1078, Valid Accounts, if the attacker leverages legitimate credentials but abuses concurrent access patterns, or more broadly fits into lateral movement and persistence strategies where state manipulation allows an adversary to maintain control over automated agents without detection. The ability to corrupt task states remotely makes this a high-severity issue for any deployment of a2a-rs that exposes its API endpoints publicly or within untrusted networks. It highlights the importance of rigorous concurrency testing in backend services, especially those built with asynchronous runtimes where race conditions are often subtle and difficult to reproduce deterministically without specialized fuzzing tools.
To mitigate this risk, immediate action is required by applying the patch identified as commit 7050c7d329238539424ee46440e23b91c4825bee to all affected instances running version 0.4.4 or earlier. This update introduces proper synchronization mechanisms, likely involving RwLock or Mutex wrappers around the shared data structures within InMemoryTaskStore, ensuring that updates are serialized and atomic relative to other concurrent operations. Organizations should verify their deployment configurations to ensure no legacy versions remain in production environments. Additionally, implementing rate limiting on task update endpoints can reduce the likelihood of successful exploitation by throttling high-frequency concurrent requests. Regular security audits focusing on concurrency patterns in asynchronous Rust codebases are recommended to prevent similar issues from arising in future development cycles.