GHSA-QW47-MCM5-934W
Vulnerability from github – Published: 2026-10-20 21:05 – Updated: 2026-10-20 21:05Draft 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 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):
- 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.
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
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.a2aproject.sdk:a2a-java-sdk-server-common"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.3.0.Final"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-111764"
],
"database_specific": {
"cwe_ids": [
"CWE-1188",
"CWE-862"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-20T21:05:09Z",
"nvd_published_at": "2026-10-20T16:17:00Z",
"severity": "HIGH"
},
"details": "Draft text for GHSA-qw47-mcm5-934w. The body below drops into the GitHub advisory description\nfield; the metadata block maps to the form fields. Set the patched version at release; publish\nwhen the fix ships._\n\n---\n\n- **Ecosystem:** Maven\n- **Affected package:** `org.a2aproject.sdk:a2a-java-sdk-server-common` (task store / authorization)\n- **Affected versions:** `\u003c= 1.2.0.Final` (and `1.2.1.Final-SNAPSHOT` on `main` prior to the fix)\n- **Patched version:** _(the release that carries the fix, e.g. 1.2.1.Final)_\n- **CWE:** CWE-1188 (Insecure Default Initialization), CWE-862 (Missing Authorization)\n- **Severity:** High\n- **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)\n\n---\n\n## Details\n\nThe default task store performs no authorization on task reads. `InMemoryTaskStore`\u0027s no-arg\nconstructor sets `authorizationProvider = null`, and `InMemoryTaskStore.get(String taskId)` is a\nbare map lookup with no authorization check regardless of provider:\n\n```java\npublic InMemoryTaskStore() {\n this.authorizationProvider = null; // default wiring\n}\n\n@Override\npublic @Nullable Task get(String taskId) {\n return tasks.get(taskId); // no owner / caller check\n}\n```\n\nAuthorization is enforced only when the application both supplies a `TaskAuthorizationProvider`\n*and* routes requests through `AuthorizationRequestHandlerDecorator` (via CDI), which checks\nownership before delegating. A server that uses the default store, or wires\n`DefaultRequestHandler.builder().build()` manually, or integrates through a non-CDI stack (e.g.\nSpring), never reaches that check. The safe posture is therefore opt-in and the shipped default is\nthe unsafe one. A caller can read a task created by another caller simply by knowing or guessing\nits id.\n\n## Summary\n\nWith the SDK\u0027s default configuration, task reads are not authorized: any caller can retrieve a\ntask (including its status, context, message history, and artifacts) created by another caller,\nby supplying the task id.\n\n## PoC\n\nUsing only the real production classes wired the default way (no mocks):\n\n1. Construct the default store: `InMemoryTaskStore store = new InMemoryTaskStore();` (no-arg\n constructor, so no authorization provider).\n2. As one caller, save a task: `store.save(victimTask, false);` with id `victim-task-42`.\n3. As a second, unrelated caller with no auth context, read it back: `store.get(\"victim-task-42\")`.\n\nThe second caller receives the first caller\u0027s task in full, with no authorization check:\n\n```\nunauthenticated get(victim-task-42) returned task owned by nobody-checked: victim-task-42 / ctx=victim-ctx\n```\n\nVerified on `main` (commit `72d220c`, JDK 21) and reproduces unchanged on `1.2.0.Final`.\n\n## Impact\n\nTask data crosses caller boundaries with no authorization. In any multi-caller deployment built on\nthe default wiring, one caller can enumerate and read another caller\u0027s tasks, including task status,\ncontext id, the message history, and any artifacts the task carries, which for agent workloads is\nfrequently sensitive input and generated content. Because the insecure behaviour is the default\nrather than a misconfiguration, it is easy to ship unintentionally, and in the default/reference\ndeployment the transport endpoints are served without authentication enforced, so the read is\nreachable by an unauthenticated caller (`PR:N`). CVSS is scored against the default configuration\nas shipped.\n\n## Remediation\n\nFail closed by default: deny task reads when no authorization provider is configured, rather than\ntreating a missing provider as allow-all, and apply the authorization check in the store\u0027s `get`\npath (not only in `list` and the CDI decorator) so it holds regardless of how the handler is\nwired. If the current permissive default is retained for single-user/testing scenarios, emit a\nprominent startup warning when the server comes up with no authorization provider so it cannot be\nshipped by accident.\n\n## Workarounds\n\nUntil a fixed release, configure a `TaskAuthorizationProvider` and ensure requests are routed\nthrough the authorization decorator (CDI wiring), rather than relying on the default no-arg store\nor a manually built handler.\n\n## References\n\n- CWE-1188: Insecure Default Initialization of Resource: https://cwe.mitre.org/data/definitions/1188.html\n- CWE-862: Missing Authorization: https://cwe.mitre.org/data/definitions/862.html",
"id": "GHSA-qw47-mcm5-934w",
"modified": "2026-10-20T21:05:09Z",
"published": "2026-10-20T21:05:09Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/a2aproject/a2a-java/security/advisories/GHSA-qw47-mcm5-934w"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-111764"
},
{
"type": "WEB",
"url": "https://github.com/a2aproject/a2a-java/pull/1095"
},
{
"type": "WEB",
"url": "https://github.com/a2aproject/a2a-java/commit/efb4e985e99390c4fc1f78c0a187a4254c0a2553"
},
{
"type": "PACKAGE",
"url": "https://github.com/a2aproject/a2a-java"
},
{
"type": "WEB",
"url": "https://github.com/a2aproject/a2a-java/releases/tag/v1.3.0.Final"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "A2A Java SDK has a fail-open default task authorization"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.