Summary
A2A Java SDK versions before 1.3.0.Final may allow task reads without verifying that the requesting caller is authorized to access the task. In multi-caller deployments using default or incompletely configured request handling, an unauthenticated caller who knows or guesses a task ID may retrieve task status, context identifiers, message history, and artifacts.
A2A Java SDK versions before 1.3.0.Final may allow task reads without verifying that the requesting caller is authorized to access the task. In multi-caller deployments using default or incompletely configured request handling, an unauthenticated caller who knows or guesses a task ID may retrieve task status, context identifiers, message history, and artifacts.
Affected context
The issue occurs in deployments using the A2A Java SDK's in-memory task store when no effective task authorization provider and authorization request-handler decorator are configured. The default store constructor leaves authorization disabled, and manually constructed or framework-integrated request handlers may omit the decorator. Exposure is most significant when multiple callers share a service and transport endpoints do not independently enforce authentication.
The issue occurs in deployments using the A2A Java SDK's in-memory task store when no effective task authorization provider and authorization request-handler decorator are configured. The default store constructor leaves authorization disabled, and manually constructed or framework-integrated request handlers may omit the decorator. Exposure is most significant when multiple callers share a service and transport endpoints do not independently enforce authentication.
Exploit preconditions
- Attack surface: A2A task-read request handling and the in-memory task store
- Required access: Network reachability to a task-reading endpoint; the default/reference transport may permit unauthenticated access
- Trigger point: A request to read a task using a known or guessed task identifier
- Why exploitation is possible: The default store can return task data without checking the caller or task owner when no effective authorization provider and decorator check are installed
- Attack surface: A2A task-read request handling and the in-memory task store
- Required access: Network reachability to a task-reading endpoint; the default/reference transport may permit unauthenticated access
- Trigger point: A request to read a task using a known or guessed task identifier
- Why exploitation is possible: The default store can return task data without checking the caller or task owner when no effective authorization provider and decorator check are installed
Why this happens
The underlying bug is a missing authorization check in the default task-read path. InMemoryTaskStore can be created with a null authorization provider, and its read operation returns stored task data without verifying ownership or caller permissions. Authorization is implemented as an optional integration through a TaskAuthorizationProvider and AuthorizationRequestHandlerDecorator, so default wiring or manually built handlers can leave the security control absent. This maps primarily to CWE-862: Missing Authorization, with CWE-1188: Insecure Default Initialization of Resource, because the default configuration does not establish a protective authorization boundary.
The underlying bug is a missing authorization check in the default task-read path. InMemoryTaskStore can be created with a null authorization provider, and its read operation returns stored task data without verifying ownership or caller permissions. Authorization is implemented as an optional integration through a TaskAuthorizationProvider and AuthorizationRequestHandlerDecorator, so default wiring or manually built handlers can leave the security control absent. This maps primarily to CWE-862: Missing Authorization, with CWE-1188: Insecure Default Initialization of Resource, because the default configuration does not establish a protective authorization boundary.
Potential impact
- An attacker may retrieve another caller's task status
- Task context identifiers and message history could be disclosed
- Stored artifacts may be exposed to unauthorized callers
- Sensitive workflow or agent interaction data can be inferred
- Information disclosure could support follow-on attacks against connected systems
- An attacker may retrieve another caller's task status
- Task context identifiers and message history could be disclosed
- Stored artifacts may be exposed to unauthorized callers
- Sensitive workflow or agent interaction data can be inferred
- Information disclosure could support follow-on attacks against connected systems
General mitigation guidance
Mitigation generally focuses on making authorization mandatory for every task-read path rather than treating it as an optional integration.
Common defensive patterns include:
- Require an effective authorization provider before serving task data
- Apply authorization checks consistently through framework, default, and manually constructed request handlers
- Enforce authentication and authorization at the transport boundary
- Bind task identifiers to authenticated principals or tenant scopes
- Fail closed when authorization configuration is absent or incomplete
- Limit task contents and artifact access according to least privilege
- Avoid exposing shared in-memory task stores across unrelated callers unless isolation is enforced
Mitigation generally focuses on making authorization mandatory for every task-read path rather than treating it as an optional integration.
Common defensive patterns include:
- Require an effective authorization provider before serving task data
- Apply authorization checks consistently through framework, default, and manually constructed request handlers
- Enforce authentication and authorization at the transport boundary
- Bind task identifiers to authenticated principals or tenant scopes
- Fail closed when authorization configuration is absent or incomplete
- Limit task contents and artifact access according to least privilege
- Avoid exposing shared in-memory task stores across unrelated callers unless isolation is enforced
How teams detect issues like this
Organizations can look for:
- Static analysis rules identifying task-store reads that lack authorization checks
- Code review signals such as nullable authorization providers or request handlers built without authorization decorators
- Integration tests that attempt cross-user task reads with valid and invalid identities
- Configuration and policy checks requiring authentication on task transport endpoints
- Runtime monitoring for repeated task-ID enumeration or reads across tenant boundaries
Automated code review and dependency analysis tools may help identify insecure defaults and missing authorization paths, but should be supplemented with end-to-end access-control tests.
Organizations can look for:
- Static analysis rules identifying task-store reads that lack authorization checks
- Code review signals such as nullable authorization providers or request handlers built without authorization decorators
- Integration tests that attempt cross-user task reads with valid and invalid identities
- Configuration and policy checks requiring authentication on task transport endpoints
- Runtime monitoring for repeated task-ID enumeration or reads across tenant boundaries
Automated code review and dependency analysis tools may help identify insecure defaults and missing authorization paths, but should be supplemented with end-to-end access-control tests.
