Summary
A2A Java SDK has a fail-open default task authorization
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(and1.2.1.Final-SNAPSHOTonmainprior 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 wiresDefaultRequestHandler.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.
PoC
Using only the real production classes wired the default way (no mocks):
- Construct the default store:
InMemoryTaskStore store = new InMemoryTaskStore();(no-arg
constructor, so no authorization provider). - As one caller, save a task:
store.save(victimTask, false);with idvictim-task-42. - 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.
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
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.
The application does not perform an authorization check before performing a sensitive operation. Typical impact: unauthorized access to restricted functionality or data.
CVE-2026-111764 has a CVSS score of 7.5 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.3.0.Final); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
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.
Frequently Asked Questions
- What is CVE-2026-111764? CVE-2026-111764 is a high-severity missing authorization vulnerability in org.a2aproject.sdk:a2a-java-sdk-server-common (maven), affecting versions < 1.3.0.Final. It is fixed in 1.3.0.Final. The application does not perform an authorization check before performing a sensitive operation.
- How severe is CVE-2026-111764? CVE-2026-111764 has a CVSS score of 7.5 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of org.a2aproject.sdk:a2a-java-sdk-server-common are affected by CVE-2026-111764? org.a2aproject.sdk:a2a-java-sdk-server-common (maven) versions < 1.3.0.Final is affected.
- Is there a fix for CVE-2026-111764? Yes. CVE-2026-111764 is fixed in 1.3.0.Final. Upgrade to this version or later.
- Is CVE-2026-111764 exploitable, and should I be worried? Whether CVE-2026-111764 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-111764 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-111764? Upgrade
org.a2aproject.sdk:a2a-java-sdk-server-commonto 1.3.0.Final or later.