GHSA-9rhm-2h4x-jwmx: Maven/org.a2aproject.sdk:a2a-java-sdk-parent vulnerability
Impact. A malicious or compromised A2A agent can cause the client's API key credential to be forwarded to an arbitrary third-party server. The agent serves an AgentCard with an APIKeySecurityScheme specifying a custom header name, then responds with an HTTP redirect. The JDK HttpClient follows the redirect and forwards the custom header containing the credential, since only the standard Authorization header may be stripped on cross-origin redirects.
Where. client/transport/spi/src/main/java/org/a2aproject/sdk/client/transport/spi/interceptors/auth/AuthInterceptor.java:69 in intercept
What. The apiKeySecurityScheme.name() field from the remote agent's AgentCard (untrusted, server-controlled data) is used directly as the HTTP header name when placing client credentials. Combined with JdkA2AHttpClient's followRedirects(NORMAL) policy, credentials under custom header names survive cross-origin redirects (only Authorization is stripped on newer JDKs), allowing a malicious agent to leak client credentials to third-party servers. Additionally, AuthInterceptor does not check that location==HEADER before placing the credential as a header.
Exploit scenario. Client configures an API key credential for agent's security scheme myAuth. The malicious agent returns an AgentCard where securitySchemes includes myAuth as APIKeySecurityScheme with name='X-Leaked-Cred' and location=HEADER. AuthInterceptor places the credential in the X-Leaked-Cred header. The agent responds with HTTP 302 redirect to https://evil.com/collect. JdkA2AHttpClient follows the redirect, forwarding all custom headers including X-Leaked-Cred to evil.com. The attacker captures the client's credential.
Preconditions. - Client application has configured API key credentials via CredentialService for the agent's security scheme - The agent is malicious or compromised (controls its own AgentCard response) - The default JdkA2AHttpClient is used (with followRedirects=NORMAL) - The JDK version does not strip custom headers on cross-origin redirects (all current versions)
Fix. Validate the APIKeySecurityScheme.name() field against a whitelist of safe header names. Check that apiKeySecurityScheme.location() equals Location.HEADER before placing the credential as a header. Consider using followRedirects(NEVER) and implementing manual redirect handling that strips all authentication headers on cross-origin redirects.
Verification. 2/3 lens verifiers confirmed.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven/org.a2aproject.sdk:a2a-java-sdk-parentto a version that resolves this vulnerability.Fixed in 1.3.0.Final - Configuration
Validate the APIKeySecurityScheme.name() field against a whitelist of safe header names, and check that apiKeySecurityScheme.location() equals Location.HEADER before placing the credential in a header.
AuthInterceptor APIKeySecurityScheme.name() and location() = Whitelist safe header names and require location() == HEADER - Configuration
Use followRedirects(NEVER); if redirects are handled manually, strip all authentication headers on cross-origin redirects.
JdkA2AHttpClient followRedirects = NEVER
Event History
Frequently Asked Questions
Which deployments are exposed?
Clients are exposed when they obtain an APIKeySecurityScheme from an A2A agent's AgentCard and send the corresponding API key through JdkA2AHttpClient. A malicious or compromised agent can control the scheme's header name and trigger the redirect behavior.
What does an attacker need to do to obtain a credential?
The attacker needs to operate or compromise an A2A agent so it serves an AgentCard specifying a custom API-key header name, then return an HTTP redirect to a third-party server. The JDK HTTP client follows normal redirects and may forward that custom credential header across origins.
Is a nonstandard API-key placement relevant?
Yes. AuthInterceptor places the credential in an HTTP header without verifying that the security scheme location is HEADER, so it does not enforce the declared credential location before adding the header.