---
id: "CVE-2026-111764"
kind: "vulnerability"
aliases: ["CVE-2026-111764", "GHSA-qw47-mcm5-934w"]
title: "A2A Java SDK has a fail-open default task authorization"
severity: "high"
cvss: 7.5
epss: 0.006039999891072512
exploited: false
status: "open"
category: "ai-tooling"
products: [{"name": "org.a2aproject.sdk:a2a-java-sdk-server-common", "fixed": ["1.3.0.Final"], "affected": "< 1.3.0.Final", "ecosystem": "maven"}]
ecosystems: ["maven"]
tags: ["a2a-java-sdk", "agent-to-agent", "ai-tooling", "cwe-1188", "cwe-862", "java", "maven", "multi-caller", "spring"]
not_affected_if: ["auth-provider-configured", "single-caller", "version-1.3.0-or-later"]
published_at: "2026-10-20T16:17:00+00:00"
first_seen_at: "2026-10-23T19:11:32+00:00"
updated_at: "2026-10-23T21:57:20+00:00"
sources: [{"source": "ghsa", "url": "https://github.com/advisories/GHSA-qw47-mcm5-934w", "first_seen_at": "2026-10-23T19:11:32+00:00"}, {"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-111764", "first_seen_at": "2026-10-23T21:57:20+00:00"}]
---

# A2A Java SDK has a fail-open default task authorization

The A2A Java SDK's default in-memory task store does not check who is asking before returning a task. Any caller who knows or guesses a task id can read another caller's task status, context, message history and artifacts.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- maven:org.a2aproject.sdk:a2a-java-sdk-server-common affected < 1.3.0.Final fixed 1.3.0.Final

## How to check

Check whether org.a2aproject.sdk:a2a-java-sdk-server-common is below 1.3.0.Final in your build (e.g. mvn dependency:tree | grep a2a).
Check whether a TaskAuthorizationProvider is configured and requests route through AuthorizationRequestHandlerDecorator (CDI); if not, the default store is in use.

## Fix

Upgrade org.a2aproject.sdk:a2a-java-sdk-server-common to 1.3.0.Final.
Until then, configure a TaskAuthorizationProvider and route requests through the CDI authorization decorator instead of the default no-arg InMemoryTaskStore.

## Timeline

- 2026-10-23T19:11:32+00:00 ghsa https://github.com/advisories/GHSA-qw47-mcm5-934w
- 2026-10-23T21:57:20+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-111764

## From the sources

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:

```java
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 `TaskAuthorizationProvider` and ensure requests are routed
through the authorization decorator (CDI wiring), rather than relying on the default no-arg store
or a manually built handler.

## References

- CWE-1188: Insecure Default Initialization of Resource: https://cwe.mitre.org/data/definitions/1188.html
- CWE-862: Missing Authorization: https://cwe.mitre.org/data/definitions/862.html

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_