A2A Java SDK EUVD-2026-105127

Exploitation requires all of: (1) the client application has configured API key credentials through CredentialService for the agent's APIKeySecurityScheme; (2) the client uses the default JdkA2AHttpClient, which calls followRedirects(NORMAL); (3) the attacker controls the agent's AgentCard and can declare an arbitrary APIKeySecurityScheme name (and a non-HEADER location that pre-patch code ignores); and (4) the attacker controls the agent's HTTP response to issue a cross-origin redirect to a third-party host. LIMITING FACTORS: only deployments that actually configure API key authentication and connect to a malicious or compromised agent are affected; clients not using the default JDK-based HTTP client, or not using header-based API key credentials, are not exposed. No per-request end-user interaction is needed once the client is configured to talk to the agent.

Signals point to a genuine but moderate-priority issue, not a top-of-queue emergency. The vendor CVSS 4.0 score is 5.7 (Medium) with vector AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N, reflecting high confidentiality impact (API key disclosure) but no integrity or availability impact. No EPSS score, no CISA KEV listing, and no SSVC decision data were provided, so exploitation-probability and automatability signals are simply absent rather than low - treat them as unknown. No public exploit was identified; the only code artifact is the fix PR (#1097), which is a patch, not a weaponized POC. CONFLICT TO VERIFY: the vendor assigned AV:L (local), yet the described attack is carried out by a remote agent server over the network via a cross-origin HTTP redirect, which maps more naturally to AV:N - the local rating appears to treat the pre-existing local credential configuration as the attack context; verify with the vendor advisory before using AV for prioritization. Realistically this requires a victim that (a) uses the default JDK client, (b) has configured API key credentials, and (c) connects to an attacker-controlled or compromised agent, so it is better characterized as targeted/opportunistic credential theft within A2A deployments than as broad, automatable mass exploitation.

A client application is configured via CredentialService with an API key for a remote A2A agent whose AgentCard the attacker controls (either a malicious agent or a compromised legitimate one). The agent returns a cross-origin HTTP redirect, and because the default JdkA2AHttpClient uses followRedirects(NORMAL) and AuthInterceptor injects the API key into an attacker-named header without verifying the scheme's declared HEADER location, the credential-bearing custom header is forwarded to the attacker's third-party server even though the standard Authorization header would be stripped. No public exploit code was identified at time of analysis; only the vendor fix (PR #1097) is available.