CVE-2026-111764High· 7.5▾ MidnightPoC availableA2A Java SDK has a fail-open default task authorization
▾ Midnight zone — Critical, or high with PoC / in-the-wild
impact 41.3 · likelihood 0.1 · exploitation 12
A public proof-of-concept already exists for this vulnerability — see Exploit availability below.
Stakeholder-Specific Vulnerability Categorization from CISA's ADP record at CVE.org: whether exploitation is observed, whether an attack can be automated, and how much of the system is at stake.
Exploit-prediction probability, daily snapshots since Oct 22.
Disclosure to exploitation, from the record and what we observed since indexing it.
Disclosed via GHSA
Exploit / PoC code exists
0.6%
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._
org.a2aproject.sdk:a2a-java-sdk-server-common (task store / authorization)<= 1.2.0.Final (and 1.2.1.Final-SNAPSHOT on main prior to the fix)CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N (7.5, High)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.
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.
Using only the real production classes wired the default way (no mocks):
InMemoryTaskStore store = new InMemoryTaskStore(); (no-arg
constructor, so no authorization provider).store.save(victimTask, false); with id victim-task-42.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.
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.
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.
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.
org.a2aproject.sdk:a2a-java-sdk-server-common < 1.3.0.FinalUpgrade to a patched release:
org.a2aproject.sdk:a2a-java-sdk-server-common 1.3.0.FinalField changes observed since this record was first indexed.
Connected by shared product, vendor, weakness, or advisory.
CVE-2026-111761Medium· 5.8A2A Java SDK has Server-Side Request Forgery (SSRF) in push-notification delivery
CVE-2026-90820Medium· 4.3A security vulnerability has been detected in a2aproject a2a-java 1.2.0
CVE-2026-111763Medium· 5.7A2A Java SDK send client credentials under server-controlled HTTP header name, enabling leakage via redirect
CVE-2026-111762Medium· 5.7A2A Java SDK: Push notification credentials logged in cleartext on protobuf parse failure
CVE-2026-117507Medium· 5.4a2aproject a2a-java TaskManager.saveTaskEvent race condition
CVE-2026-117506Medium· 4.3a2aproject a2a-java Push Notification Config Store JpaDatabasePushNotificationConfigStore.java InMemoryPushNotificationConfigStore.setInfo resource consumption