A2A Java SDK has a fail-open default task authorization

Why it is Amber

• CVSS 7.5 high
• Remotely exploitable without logging in
• On your watchlist: Maven

Affected packages

References

• https://github.com/advisories/GHSA-qw47-mcm5-934w
• https://github.com/a2aproject/a2a-java/security/advisories/GHSA-qw47-mcm5-934w
• https://nvd.nist.gov/vuln/detail/CVE-2026-111764
• https://github.com/a2aproject/a2a-java/pull/1095
• https://github.com/a2aproject/a2a-java/commit/efb4e985e99390c4fc1f78c0a187a4254c0a2553
• https://github.com/a2aproject/a2a-java/releases/tag/v1.3.0.Final
• https://github.com/advisories/GHSA-qw47-mcm5-934w

Original description

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.