CVE-2026-111764 in a2a-java
Summary
by MITRE • 10/20/2026
A2A Java SDK is the official Java SDK for the Agent2Agent (A2A) Protocol. Prior to 1.3.0.Final, the default InMemoryTaskStore configuration performs no authorization on task reads: the no-argument constructor sets authorizationProvider to null, and InMemoryTaskStore.get(String taskId) returns the stored task without checking the caller or owner. Authorization depends on supplying a TaskAuthorizationProvider and routing requests through AuthorizationRequestHandlerDecorator, whether installed through CDI or explicitly by the application. Default store wiring and manually constructed DefaultRequestHandler.builder().build() handlers, including integrations such as Spring, leave task reads unprotected when no effective authorization-provider and decorator check is installed. In a multi-caller deployment using the default configuration, a caller who knows or guesses another caller's task ID can retrieve the task status, context ID, message history, and artifacts. The default/reference transport endpoints do not enforce authentication, so the task-read disclosure is reachable by an unauthenticated caller rather than requiring a privileged account. This issue is fixed in version 1.3.0.Final.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/20/2026
The Agent2Agent Java SDK serves as the official implementation for the A2A Protocol, facilitating communication between autonomous agents. Within this framework, task management is critical for maintaining state and context across agent interactions. Prior to version 1.3.0.Final, a significant security flaw existed in the default configuration of the InMemoryTaskStore component. This vulnerability stems from an insecure direct object reference mechanism where the system fails to enforce access controls on read operations by design when using standard initialization methods. The root cause lies in the no-argument constructor of InMemoryTaskStore, which initializes the authorizationProvider field to null. Consequently, when a request is processed via the get method with a specific task identifier, the store retrieves and returns the associated task data without performing any verification regarding the identity or permissions of the requesting entity. This design oversight means that access control logic is entirely bypassed unless explicitly configured by the application developer through non-default pathways.
The operational impact of this flaw is severe in multi-caller deployments where multiple agents or users interact with the same instance. An attacker who can predict, guess, or otherwise obtain a valid task identifier for another caller can exploit this lack of authorization to retrieve sensitive information. The exposed data includes the current status of the task, the context ID which may reveal session details, the complete message history between agents, and any artifacts generated during the process. This constitutes a serious breach of confidentiality, potentially exposing proprietary logic, personal data, or internal system states depending on the application's use case. Furthermore, because the default reference transport endpoints do not enforce authentication mechanisms at the network level, this vulnerability is reachable by unauthenticated actors. An external attacker does not need valid credentials to initiate these requests; they only require knowledge of a target task ID, making exploitation straightforward and accessible via standard HTTP methods without any prior login or token validation steps.
From a classification perspective, this vulnerability aligns with CWE-284, which describes Improper Access Control, specifically the failure to enforce restrictions on data access based on identity. It also maps closely to CWE-639, Injection of Incorrect IDentifier, as exploitation relies on manipulating or guessing object identifiers that are not validated against user permissions. In terms of offensive security frameworks, this behavior is consistent with ATT&CK technique T1078, Valid Accounts, although in this specific case, the lack of authentication means it can be exploited even without valid credentials if task IDs are discoverable through enumeration or leakage from other sources such as error messages or logs. The vulnerability highlights a common pitfall in framework design where security features are opt-in rather than default-secure, leaving applications vulnerable when developers assume built-in protections exist by default.
To mitigate this risk, organizations using versions of the A2A Java SDK prior to 1.3.0.Final must immediately upgrade to version 1.3.0.Final or later, where these authorization checks are enforced by default in standard configurations. For applications that cannot yet upgrade, a temporary mitigation involves explicitly configuring a TaskAuthorizationProvider and ensuring that all requests are routed through an AuthorizationRequestHandlerDecorator. This can be achieved either through CDI injection if the environment supports it or by manually constructing DefaultRequestHandler instances with proper security decorators enabled. Additionally, developers should implement authentication mechanisms at the transport layer to prevent unauthenticated access to endpoints entirely. It is also advisable to review task ID generation strategies to ensure they are unpredictable and not easily guessable, thereby reducing the attack surface even if authorization controls were previously overlooked in custom implementations.