Skip to main content

A2A Java SDK CVE-2026-111764

| EUVDEUVD-2026-105130 HIGH
Missing Authorization (CWE-862)
2026-10-20 GitHub_M GHSA-qw47-mcm5-934w
7.5
CVSS 3.1 · Vendor: GitHub_M
View

Attack ChainAIDerived

Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain

  1. Access
    Reach unauthenticated reference transport endpoint
  2. Exploit
    Obtain or enumerate another caller's task ID
  3. Execution
    Invoke task-read (InMemoryTaskStore.get)
  4. Impact
    Disclose task status, context ID, message history and artifacts

Vulnerability Assessment

Weakness
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization checks on every request
MITRE ATT&CK

1 technique across 1 tactic: Privilege Escalation

The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up.

Exploitation Conditions

Requires a multi-caller/multi-tenant deployment of the A2A Java SDK prior to 1.3.0.Final using the default task-store wiring: the no-argument InMemoryTaskStore constructor leaves authorizationProvider null, and no TaskAuthorizationProvider plus AuthorizationRequestHandlerDecorator is installed (via CDI or explicitly). This includes manually built DefaultRequestHandler.builder().build() handlers and integrations such as Spring. Because the default/reference transport endpoints do not enforce authentication, the task-read disclosure is reachable without any account. LIMITING FACTORS: single-user deployments and any deployment that configures a TaskAuthorizationProvider/decorator (or upgrades to 1.3.0.Final, which defaults to fail-closed) are not exposed; the attacker must also know or guess a valid target task ID, so the impact is confined to callers whose task IDs can be obtained or enumerated.

Impact

This is a genuine access-control weakness (CWE-862, Missing Authorization) in the A2A Java SDK's default InMemoryTaskStore, scored CVSS 7.5 with a clean network vector (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N). The signals are internally consistent: the description confirms the reference transport endpoints do not enforce authentication and InMemoryTaskStore.get(taskId) returns tasks without any owner/caller check, which supports AV:N, AC:L, PR:N, UI:N, and a pure confidentiality impact (C:H / I:N / A:N). Exploitation status is 'no public exploit identified at time of analysis' - no EPSS score, no CISA KEV listing, and no POC indicator were provided in the input, so there is no evidence of active or widespread exploitation; this is a vendor/GitHub-advisory-driven disclosure with a patch, not a KEV-confirmed in-the-wild issue. The one qualifier that lowers real-world risk below the raw 7.5 is a non-CVSS prerequisite stated in the description: the flaw only matters in a multi-caller/multi-tenant deployment using the default (no authorization-provider) configuration, and the attacker must know or guess another caller's task ID (IDOR-style). The low value sits in CVSS complexity terms but is a meaningful limiter operationally. SSVC-style read: exploitation = none observed, automatable = yes (task-read requests can be scripted/ID-enumerated), technical impact = partial (information disclosure only, no integrity/availability). Net: a real priority for anyone running the pre-1.3.0.Final SDK in a shared/multi-tenant mode, but lower urgency for single-user or already authorization-decorated deployments.

Exploit ScenarioDerived

An organization runs an A2A agent server built on the A2A Java SDK (e.g., via Spring or a manually built DefaultRequestHandler) serving multiple callers, with the default InMemoryTaskStore and no TaskAuthorizationProvider. An unauthenticated attacker who learns or guesses a victim caller's task ID issues a task-read request to the unprotected reference transport endpoint and receives that task's status, context ID, full message history, and artifacts belonging to another caller. No public exploit code was identified in the provided data, but exploitation requires only a standard protocol request, so it is easily scriptable.

This Week Schedule remediation this week. Why: HIGH severity (CVSS 7.0-8.9).
Patch available 0.6% exploitation probability (EPSS)

Get an e-mail when this CVE is exploited, patched or re-scored. Free account.

Alert me

AnalysisAIv1 – Oct 20, 2026

Unauthenticated task-read disclosure in the A2A Java SDK before 1.3.0.Final lets any network caller retrieve another caller's task status, context ID, message history, and artifacts by supplying a task ID. The default no-argument InMemoryTaskStore constructor leaves authorizationProvider null, so InMemoryTaskStore.get(String taskId) returns stored tasks without any owner or caller check unless a TaskAuthorizationProvider is wired through the AuthorizationRequestHandlerDecorator - a wiring that manual DefaultRequestHandler.builder().build() setups and integrations such as Spring commonly skip. Because the default/reference transport endpoints also perform no authentication, the exposure is reachable without an account in multi-caller deployments; exploitation additionally requires the attacker to know or guess a valid task ID, and no public exploit code has been identified at time of analysis.

RemediationAI

Upgrade to 1.3.0.Final, the vendor-released patch (see the GHSA-qw47-mcm5-934w advisory, PR #1095, and commit efb4e985e99390c4fc1f78c0a187a4254c0a2553). The upgrade inverts the default to fail-closed - with no TaskAuthorizationProvider configured, all task operations are denied - so multi-tenant deployments get protection without further code changes, while single-user deployments and test profiles that relied on the old permissive behavior must explicitly set a2a.authorization.required=false in their properties or call .authorizationRequired(false) on the request-handler builder, which reopens the same disclosure and should not be used in production. For deployments that cannot upgrade immediately, implement a TaskAuthorizationProvider that enforces an owner check on every task read and ensure requests are routed through AuthorizationRequestHandlerDecorator - obtain the RequestHandler via CDI injection rather than manual DefaultRequestHandler.create()/builder().build() instantiation, since manual construction bypasses the decorator; the trade-off is that this requires application code changes and correct ownership metadata on each task. Additionally, place authentication in front of the reference transport endpoints (JSON-RPC, gRPC, REST) to prevent anonymous callers from reaching the task store at all, and avoid predictable or enumerable task IDs as a defense-in-depth measure - though neither substitutes for the authorization fix.

Affected VersionsENISA

a2a-java < 1.3.0.Final

Affected Packages

maven org.a2aproject.sdk:a2a-java-sdk-server-common fix: 1.3.0.Final
euvd a2a_java fix: 1.3.0.Final

Source: OSV (Open Source Vulnerabilities)

Affects your stack

Affects 2 packages in maven, euvd

Checking this CVE against your own stacks and servers is part of the Basic plan and up.

Technical ContextAI · show details

The A2A Java SDK is the reference Java implementation of the Agent2Agent (A2A) protocol, exposing agent tasks over JSON-RPC, gRPC, and REST transports. Task authorization is implemented as an opt-in layer: the SDK relies on an application-supplied TaskAuthorizationProvider bean, discovered via CDI or passed explicitly, plus the AuthorizationRequestHandlerDecorator that invokes it before each handler operation. The default InMemoryTaskStore's no-argument constructor sets authorizationProvider to null, and its get(String taskId) method returns whatever is stored without consulting an owner - a textbook CWE-862 (Missing Authorization) fail-open design. The upstream fix (PR #1095, commit efb4e985e99390c4fc1f78c0a187a4254c0a2553, released as v1.3.0.Final) inverts the default to fail-closed: the SDK now denies all task operations when no provider is configured, introduces the a2a.authorization.required property (default true) and the builder's authorizationRequired(false) escape hatch for single-user or test deployments, and documents that authorization is enforced even when DefaultRequestHandler.builder() is used directly rather than obtained through CDI injection. The upstream diff shows the authorization documentation being rewritten from 'all operations are permitted regardless of authentication' to 'all task operations are denied when no TaskAuthorizationProvider is configured.'

Know when A2A Java gets its next vulnerability

  • Watch products and get an email when something new is published
  • Check this CVE against your own stack and servers
  • Exploit and PoC references, threat intelligence from 22 sources

No credit card · 7-day full trial

Severity by source

Vendor (GitHub_M) PRIMARY 7.5 HIGH
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
vuln.today AI 7.5 HIGH

Reference endpoints enforce no authentication (PR:N) and task-read is a direct network request (AV:N/AC:L); impact is disclosure of task data only, so C:H with I:N/A:N and unchanged scope.

3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
4.0 AV:N/AC:L/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

Primary rating from Vendor (GitHub_M).

CVSS VectorVendor: GitHub_M

Attack Vector
Network
Attack Complexity
Low
Privileges Required
None
User Interaction
None
Scope
Unchanged
Confidentiality
High
Integrity
None
Availability
None

Lifecycle Timeline

2
Patch available
Oct 20, 2026 - 17:18 EUVD
CVE Published
Oct 20, 2026 - 15:05 cve.org
HIGH 7.5

DescriptionCVE.org

A2A Java SDK is the official Java SDK for the Agent2Agent (A2A) Protocol. Prior to 1.3.0.Final, the default InMemoryTaskStore configuration performs no authorization on task reads: the no-argument constructor sets authorizationProvider to null, and InMemoryTaskStore.get(String taskId) returns the stored task without checking the caller or owner. Authorization depends on supplying a TaskAuthorizationProvider and routing requests through AuthorizationRequestHandlerDecorator, whether installed through CDI or explicitly by the application. Default store wiring and manually constructed DefaultRequestHandler.builder().build() handlers, including integrations such as Spring, leave task reads unprotected when no effective authorization-provider and decorator check is installed. In a multi-caller deployment using the default configuration, a caller who knows or guesses another caller's task ID can retrieve the task status, context ID, message history, and artifacts. The default/reference transport endpoints do not enforce authentication, so the task-read disclosure is reachable by an unauthenticated caller rather than requiring a privileged account. This issue is fixed in version 1.3.0.Final.

Technical POC Analysis

CWE-862 (Missing Authorization), with an insecure-default component (CWE-1188 as co-classified in the advisory).

Full technical POC analysis - root cause, step-by-step exploitation and patch breakdown - is part of the Pro and Business plans.

Executive ViewAI

Why It Matters

The A2A Java SDK, used to connect AI agents and services, exposes task data across callers in deployments running versions prior to 1.3.0.Final, because the default InMemoryTaskStore performs no ownership check when a task ID is supplied. Any caller able to reach a reference transport endpoint and guess or learn a valid task ID can read another party's task status, context identifiers, message history, and artifacts. Leadership should care because this is a cross-caller confidentiality exposure in a component that is insecure by default and is commonly deployed without the optional authorization wiring, placing customer and internal agent conversations at risk wherever multiple parties share an endpoint.

Business Impact: High
Compensating Controls

No vendor-released patch confirmed at time of analysis; interim mitigations are to wire a TaskAuthorizationProvider through the AuthorizationRequestHandlerDecorator so InMemoryTaskStore.get enforces owner checks, add authentication at the transport layer in front of the A2A reference endpoints, avoid the default no-argument InMemoryTaskStore in any multi-caller deployment, and restrict network access to A2A endpoints to trusted callers until A2A Java SDK 1.3.0.Final can be deployed.

Threat Intelligence Overview

EPSS Score
0.6%
Top 52% exploitable
Prevalence
Low
niche, recently-introduced agent-protocol developer SDK, limited production footprint
Threat Intel
1
1 source
Data Quality
5 sources
Confidence: Medium
EUVD NVD CVE.org EPSS Vulnrichment GHSA GitHub VulDB

How this decision was reached

The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.

SignalValue
Severity HIGH
CISA KEV No
Public POC No
EPSS 0.6%
Patch available Yes
Active threat No
Deciding rule
HIGH severity (CVSS 7.0-8.9)
What every action level means
Emergency Immediate action required. Criteria: CRITICAL + in CISA KEV (actively exploited) without patch, OR CRITICAL + EPSS > 30% without patch, OR CRITICAL + active threat signals without patch.
Act Now Prioritize within 24-48h. Criteria: in KEV with patch available, OR CRITICAL + public POC, OR HIGH + EPSS > 10%, OR CRITICAL + active threat, OR any CRITICAL severity.
This Week Schedule remediation this week. Criteria: HIGH severity (CVSS 7.0-8.9). Patch within normal change window.
This Month Plan within 30 days. Criteria: MEDIUM severity (CVSS 4.0-6.9), lower exploitation probability. Include in regular patch cycle.
Monitor Track and reassess. Criteria: LOW severity (CVSS 0.1-3.9), minimal exploitation risk. No immediate action needed.

SSVC AssessmentENISA

SSVC Decision
Scheduled
Exploitation
Poc
System Exposure· derived
Open
Automatable
Yes
Human Impact
High
Technical Impact
Partial

Priority Score

39
Low Medium High Critical
KEV: 0
EPSS: +1
CVSS: +38
PoC: 0
Weaponized: 0
Threat intel: 0
Gov advisory: 0

Attack Technique

Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.

This site uses cookies essential for authentication and security. No tracking or analytics cookies are used. Privacy Policy