a2a-rs Information Disclosure and Race Condition

Concurrent task operations in the a2a-rs Rust A2A server (through 0.4.4) can drive the in-memory task store into an inconsistent state, because InMemoryTaskStore::update performs a check-then-act sequence on a task's state without holding a lock across the decision and the write. An authenticated client able to submit task operations, and able to issue concurrent cancel or update requests for the same task ID, can win the timing window and overwrite a terminal task state or cause both of two competing cancels to be processed; impact is limited to task-state integrity and low availability effects, with no confidentiality loss. Exploitation requires the in-memory backend to be configured and is probabilistic, and no public exploit code was identified at time of analysis; CISA KEV does not list this issue.

In a2a-rs (a2a-server crate) through 0.4.3, the in-memory task store does not clamp client-supplied page-size and history-length parameters, so an authenticated low-privilege caller can request oversized result sets and pull task-history records beyond the pagination bounds the API is meant to enforce. Only deployments using InMemoryTaskStore that expose the task-list/history endpoints are affected, and the impact is limited to read-only disclosure of task metadata and message history - no write, no code execution and no denial of service. No public exploit code has been identified and the issue is not in CISA KEV, so this should be handled as a moderate-priority patch rather than an emergency (CVSS 4.0 base 5.1; assessed CVSS 3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N).