CVE-2026-111764

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.

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.

Draft text for GHSA-qw47-mcm5-934w. The body below drops into the GitHub advisory description field; the metadata block maps to the form fields. Set the patched version at release; publish when the fix ships._

• Ecosystem: Maven
• Affected package: org.a2aproject.sdk:a2a-java-sdk-server-common (task store / authorization)
• Affected versions: <= 1.2.0.Final (and 1.2.1.Final-SNAPSHOT on main prior to the fix)
• Patched version: (the release that carries the fix, e.g. 1.2.1.Final)
• CWE: CWE-1188 (Insecure Default Initialization), CWE-862 (Missing Authorization)
• Severity: High
• CVSS v3.1: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N (7.5, High)

Details

The default task store performs no authorization on task reads. InMemoryTaskStore's no-arg constructor sets authorizationProvider = null, and InMemoryTaskStore.get(String taskId) is a bare map lookup with no authorization check regardless of provider:

public InMemoryTaskStore() {
    this.authorizationProvider = null;   // default wiring
}

@Override
public @Nullable Task get(String taskId) {
    return tasks.get(taskId);            // no owner / caller check
}

Authorization is enforced only when the application both supplies a TaskAuthorizationProvider and routes requests through AuthorizationRequestHandlerDecorator (via CDI), which checks ownership before delegating. A server that uses the default store, or wires DefaultRequestHandler.builder().build() manually, or integrates through a non-CDI stack (e.g. Spring), never reaches that check. The safe posture is therefore opt-in and the shipped default is the unsafe one. A caller can read a task created by another caller simply by knowing or guessing its id.

Summary

With the SDK's default configuration, task reads are not authorized: any caller can retrieve a task (including its status, context, message history, and artifacts) created by another caller, by supplying the task id.

PoC

Using only the real production classes wired the default way (no mocks):

1. Construct the default store: InMemoryTaskStore store = new InMemoryTaskStore(); (no-arg constructor, so no authorization provider).
2. As one caller, save a task: store.save(victimTask, false); with id victim-task-42.
3. As a second, unrelated caller with no auth context, read it back: store.get("victim-task-42").

The second caller receives the first caller's task in full, with no authorization check:

unauthenticated get(victim-task-42) returned task owned by nobody-checked: victim-task-42 / ctx=victim-ctx

Verified on main (commit 72d220c, JDK 21) and reproduces unchanged on 1.2.0.Final.

Impact

Task data crosses caller boundaries with no authorization. In any multi-caller deployment built on the default wiring, one caller can enumerate and read another caller's tasks, including task status, context id, the message history, and any artifacts the task carries, which for agent workloads is frequently sensitive input and generated content. Because the insecure behaviour is the default rather than a misconfiguration, it is easy to ship unintentionally, and in the default/reference deployment the transport endpoints are served without authentication enforced, so the read is reachable by an unauthenticated caller (PR:N). CVSS is scored against the default configuration as shipped.

Remediation

Fail closed by default: deny task reads when no authorization provider is configured, rather than treating a missing provider as allow-all, and apply the authorization check in the store's get path (not only in list and the CDI decorator) so it holds regardless of how the handler is wired. If the current permissive default is retained for single-user/testing scenarios, emit a prominent startup warning when the server comes up with no authorization provider so it cannot be shipped by accident.

Workarounds

Until a fixed release, configure a…

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.

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.

Draft text for GHSA-qw47-mcm5-934w. The body below drops into the GitHub advisory description field; the metadata block maps to the form fields. Set the patched version at release; publish when the fix ships._

• Ecosystem: Maven
• Affected package: org.a2aproject.sdk:a2a-java-sdk-server-common (task store / authorization)
• Affected versions: <= 1.2.0.Final (and 1.2.1.Final-SNAPSHOT on main prior to the fix)
• Patched version: (the release that carries the fix, e.g. 1.2.1.Final)
• CWE: CWE-1188 (Insecure Default Initialization), CWE-862 (Missing Authorization)
• Severity: High
• CVSS v3.1: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N (7.5, High)

Details

The default task store performs no authorization on task reads. InMemoryTaskStore's no-arg constructor sets authorizationProvider = null, and InMemoryTaskStore.get(String taskId) is a bare map lookup with no authorization check regardless of provider:

public InMemoryTaskStore() {
    this.authorizationProvider = null;   // default wiring
}

@Override
public @Nullable Task get(String taskId) {
    return tasks.get(taskId);            // no owner / caller check
}

Authorization is enforced only when the application both supplies a TaskAuthorizationProvider and routes requests through AuthorizationRequestHandlerDecorator (via CDI), which checks ownership before delegating. A server that uses the default store, or wires DefaultRequestHandler.builder().build() manually, or integrates through a non-CDI stack (e.g. Spring), never reaches that check. The safe posture is therefore opt-in and the shipped default is the unsafe one. A caller can read a task created by another caller simply by knowing or guessing its id.

Summary

With the SDK's default configuration, task reads are not authorized: any caller can retrieve a task (including its status, context, message history, and artifacts) created by another caller, by supplying the task id.

PoC

Using only the real production classes wired the default way (no mocks):

1. Construct the default store: InMemoryTaskStore store = new InMemoryTaskStore(); (no-arg constructor, so no authorization provider).
2. As one caller, save a task: store.save(victimTask, false); with id victim-task-42.
3. As a second, unrelated caller with no auth context, read it back: store.get("victim-task-42").

The second caller receives the first caller's task in full, with no authorization check:

unauthenticated get(victim-task-42) returned task owned by nobody-checked: victim-task-42 / ctx=victim-ctx

Verified on main (commit 72d220c, JDK 21) and reproduces unchanged on 1.2.0.Final.

Impact

Task data crosses caller boundaries with no authorization. In any multi-caller deployment built on the default wiring, one caller can enumerate and read another caller's tasks, including task status, context id, the message history, and any artifacts the task carries, which for agent workloads is frequently sensitive input and generated content. Because the insecure behaviour is the default rather than a misconfiguration, it is easy to ship unintentionally, and in the default/reference deployment the transport endpoints are served without authentication enforced, so the read is reachable by an unauthenticated caller (PR:N). CVSS is scored against the default configuration as shipped.

Remediation

Fail closed by default: deny task reads when no authorization provider is configured, rather than treating a missing provider as allow-all, and apply the authorization check in the store's get path (not only in list and the CDI decorator) so it holds regardless of how the handler is wired. If the current permissive default is retained for single-user/testing scenarios, emit a prominent startup warning when the server comes up with no authorization provider so it cannot be shipped by accident.

Workarounds

Until a fixed release, configure a…