GHSA-9rhm-2h4x-jwmx

*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.