CVE-2026-111764: A2A Java SDK has a fail-open default task authorization

Q: Which deployments are exposed?

Multi-caller deployments are exposed when they use the default InMemoryTaskStore configuration or a manually constructed DefaultRequestHandler.builder().build() handler without an effective authorization provider and AuthorizationRequestHandlerDecorator check. This includes affected integrations such as Spring when those authorization components are not installed.

Q: What does an attacker need to retrieve another caller's task data?

An attacker needs to know or guess another caller's task ID. The default/reference transport endpoints do not enforce authentication, so a privileged account is not required.

Q: What information can be disclosed through an unauthorized task read?

An unauthorized caller can retrieve the task status, context ID, message history, and artifacts associated with the task.

Q: What can be done before upgrading?

Configure a TaskAuthorizationProvider and ensure requests are routed through AuthorizationRequestHandlerDecorator, either through CDI or explicitly in the application. This is necessary to enforce task-read authorization.

Q: How can I determine whether my application is affected?

Check whether InMemoryTaskStore is created with its no-argument constructor, which sets the authorization provider to null. Also verify that request handling has an effective TaskAuthorizationProvider and AuthorizationRequestHandlerDecorator rather than relying on default store wiring or an undecorated DefaultRequestHandler builder.

Published Oct 20, 2026

Updated

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.

Affected Software

1 affected component

A2A Project A2A Java SDK<1.3.0.Final

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade A2A Java SDK to a version that resolves this vulnerability.
Fixed in 1.3.0.Final
Configuration
Supply an effective TaskAuthorizationProvider and route requests through AuthorizationRequestHandlerDecorator, whether installed through CDI or explicitly by the application.
A2A Java SDK TaskAuthorizationProvider and AuthorizationRequestHandlerDecorator = configured and enabled

Event History

Oct 20, 2026

CVE Published

via MITRE·03:05 PM

Data Sourced

via MITRE·03:05 PM

DescriptionSeverityWeakness

Data Sourced

via NVD·04:17 PM

DescriptionSeverityWeakness

Frequently Asked Questions

Which deployments are exposed?

Multi-caller deployments are exposed when they use the default InMemoryTaskStore configuration or a manually constructed DefaultRequestHandler.builder().build() handler without an effective authorization provider and AuthorizationRequestHandlerDecorator check. This includes affected integrations such as Spring when those authorization components are not installed.

What does an attacker need to retrieve another caller's task data?

An attacker needs to know or guess another caller's task ID. The default/reference transport endpoints do not enforce authentication, so a privileged account is not required.

What information can be disclosed through an unauthorized task read?

An unauthorized caller can retrieve the task status, context ID, message history, and artifacts associated with the task.

What can be done before upgrading?

Configure a TaskAuthorizationProvider and ensure requests are routed through AuthorizationRequestHandlerDecorator, either through CDI or explicitly in the application. This is necessary to enforce task-read authorization.

How can I determine whether my application is affected?

Check whether InMemoryTaskStore is created with its no-argument constructor, which sets the authorization provider to null. Also verify that request handling has an effective TaskAuthorizationProvider and AuthorizationRequestHandlerDecorator rather than relying on default store wiring or an undecorated DefaultRequestHandler builder.

CVE-2026-111764: A2A Java SDK has a fail-open default task authorization

Affected Software

Remediation

Event History

Frequently Asked Questions

Which deployments are exposed?

What does an attacker need to retrieve another caller's task data?

What information can be disclosed through an unauthorized task read?

What can be done before upgrading?

How can I determine whether my application is affected?

Company

Resources

Contact

Frequently Asked Questions

Which deployments are exposed?

What does an attacker need to retrieve another caller's task data?

What information can be disclosed through an unauthorized task read?

What can be done before upgrading?

How can I determine whether my application is affected?