A2A Java SDK 1.2.0.Final Lacks Authorization Checks, Leaving Task Data Exposed With No Patch Yet

The A2A Java SDK contains a high-severity vulnerability in its server-common module. This flaw permits unauthorized access to task data when default configurations are used, and no confirmed fix has been released yet.

What happened

GitHub advisory GHSA-qw47-mcm5-934w identifies CVE-2026-111764 as a high-severity issue within the Maven ecosystem. The flaw resides in the `org.a2aproject.sdk:a2a-java-sdk-server-common` package, specifically affecting versions up to 1.2.0.Final. The source material lists 1.3.0.Final as an example of a patched version but does not confirm its release.

The vulnerability stems from insecure default initialization and missing authorization controls. The `InMemoryTaskStore` class sets its authorization provider to null by default. Consequently, the method used to retrieve tasks performs a simple map lookup without verifying caller permissions.

This behavior occurs regardless of whether an authorization provider is theoretically available. Authorization is only enforced if an application explicitly supplies a `TaskAuthorizationProvider` and routes requests through the `AuthorizationRequestHandlerDecorator` via CDI. Servers using default stores or non-CDI stacks like Spring bypass these checks entirely.

An attacker can read any task created by another user by knowing or guessing the task ID. This exposes sensitive information including status, context, message history, and artifacts. The default shipped configuration is therefore unsafe, requiring manual opt-in for security.

Why it matters

The CVSS v3.1 score for this flaw is 7.5, classified as high severity. The vector string indicates network-accessible exploitation with low complexity and no privileges required. There is no user interaction needed for successful abuse.

The impact is limited to confidentiality, with no integrity or availability loss. However, the exposure of message history and artifacts could reveal sensitive operational data. The flaw affects the core task store functionality within the SDK.

What to watch

• Monitor Maven repositories for the release of a confirmed patched version.
• Verify that existing deployments are not using the vulnerable `InMemoryTaskStore` defaults.
• Check application logs for unusual task retrieval patterns that may indicate exploitation.
• Review integration methods to ensure CDI-based authorization decorators are active.

Who needs to act first

Teams should prioritize updating systems that expose task data to external callers or untrusted internal services. Infrastructure relying on default SDK configurations requires immediate attention because those settings lack necessary authorization checks. Before deploying updates, validate changes in isolated test environments to ensure compatibility with existing application logic. Back up current configurations and data stores to facilitate rollback if integration issues arise. Monitor network traffic for anomalous access patterns during the transition period to detect potential exploitation attempts.

What to do and how to stay safe: A2A Java SDK

• Audit inventory for instances of `org.a2aproject.sdk:a2a-java-sdk-server-common` below the patched version.
• Review application code to identify uses of `InMemoryTaskStore` without explicit authorization providers.
• Implement network segmentation to limit access to services hosting vulnerable task stores.
• Enable detailed logging for task retrieval operations to detect unauthorized access attempts.

Step-by-step guide: Virtual Patching Myths: What It Actually Fixes and Breaks

General security guidance from the Patch Gazette newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Which versions of the A2A Java SDK are affected by this vulnerability?

Versions up to and including 1.2.0.Final are affected, as well as the 1.2.1.Final-SNAPSHOT on the main branch prior to the fix.

Is there a patch available for CVE-2026-111764?

No confirmed patch has been released yet; the source material lists 1.3.0.Final only as an example.

How can an attacker exploit this flaw?

An attacker can exploit this by supplying a known or guessed task ID to retrieve data from the default task store without authorization.