CVE-2026-111763 in A2A Java SDK
Summary
by MITRE • 10/20/2026
A2A Java SDK is the official Java SDK for the Agent2Agent (A2A) Protocol. Prior to 1.3.0.Final, a malicious or compromised remote agent can cause the default JDK-based client to forward a configured API key to a third-party server. When a client application configures credentials through `CredentialService`, `AuthInterceptor.intercept` in `client/transport/spi/src/main/java/org/a2aproject/sdk/client/transport/spi/interceptors/auth/AuthInterceptor.java` uses `APIKeySecurityScheme.name()` from the remote AgentCard directly as the HTTP header name containing the credential, without checking that the declared location is HEADER. JdkA2AHttpClient uses followRedirects(NORMAL), so an agent-controlled cross-origin redirect forwards the custom credential-bearing header even when the standard Authorization header is stripped. The attack requires configured API key credentials for the agent's security scheme and control of the agent's AgentCard and redirect response, but no additional client privileges. This issue is fixed in version 1.3.0.Final.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 10/20/2026
The A2A Java SDK serves as the official implementation for the Agent2Agent Protocol, facilitating secure communication between autonomous agents. However, versions prior to 1.3.0.Final contain a critical security flaw related to credential handling during HTTP interactions. This vulnerability stems from an insecure design in how authentication credentials are managed and transmitted when interacting with remote agents that may be malicious or compromised. The core issue lies within the interaction between the CredentialService configuration, the AuthInterceptor logic, and the underlying HTTP client's redirect behavior.
The technical flaw originates in the AuthInterceptor class located at client/transport/spi/src/main/java/org/a2aproject/sdk/client/transport/spi/interceptors/auth/AuthInterceptor.java. When a client application configures credentials via CredentialService for an API key security scheme, the interceptor is responsible attaching these credentials to outgoing requests. In vulnerable versions, the AuthInterceptor.intercept method blindly trusts the metadata provided in the remote AgentCard. Specifically, it uses the value returned by APIKeySecurityScheme.name() directly as the HTTP header name for the credential without validating whether this location corresponds to a standard or safe transmission mechanism such as an HTTP Header. This lack of validation allows a malicious agent to dictate how its credentials are transmitted if it controls the AgentCard metadata.
The severity of this vulnerability is significantly amplified by the default configuration of JdkA2AHttpClient, which enables followRedirects(NORMAL). Under normal circumstances, when an HTTP client follows a redirect from one origin to another, standard security practices often involve stripping sensitive headers like Authorization to prevent credential leakage across domains. However, because the AuthInterceptor injects credentials into a custom header name determined by the remote agent's AgentCard rather than a fixed, protected header, these redirects do not trigger the same stripping protections. Consequently, when an agent-controlled cross-origin redirect occurs, the HTTP client forwards the custom credential-bearing header to the third-party destination server alongside the request body and other standard headers.
This behavior results in a severe information disclosure vulnerability where API keys intended for legitimate service authentication are exfiltrated to untrusted external servers controlled by malicious actors. The operational impact is substantial as it compromises the confidentiality of sensitive authentication tokens, potentially allowing attackers to impersonate agents or access protected resources if they can intercept and utilize these leaked credentials. This attack vector aligns with CWE-201: Information Exposure Through Sent Data, specifically illustrating how improper data handling during protocol interactions leads to unauthorized disclosure. Furthermore, this scenario reflects ATT&CK technique T1539: Steal Web Session Cookie, adapted for API key contexts, where session or authentication tokens are stolen via cross-origin requests and redirects.
The exploitation of this vulnerability requires specific conditions but remains feasible in many deployment scenarios. An attacker must have the ability to configure an agent's AgentCard with a malicious security scheme definition that specifies a custom header name for credentials. Additionally, the attacker needs control over the redirect response mechanism associated with that agent so they can trigger cross-origin redirects during legitimate API calls made by victim clients using A2A SDK versions prior to 1.3.0.Final. Notably, this attack does not require any additional privileges on the client side beyond having configured API key credentials for the targeted security scheme, making it a low-barrier threat for adversaries targeting systems integrated with vulnerable A2A agents.
To mitigate this risk, organizations must upgrade to version 1.3.0.Final of the A2A Java SDK immediately upon availability. This release addresses the flaw by implementing stricter validation logic within the AuthInterceptor to ensure that credentials are only transmitted via standard, expected mechanisms and locations defined in security specifications rather than arbitrary values from remote metadata. Until an upgrade is possible, defensive measures should include restricting network egress to known trusted domains using firewall rules or proxy configurations to limit exposure if a redirect occurs. Additionally, implementing strict Content Security Policies and monitoring for unusual outbound HTTP requests carrying custom authentication headers can help detect potential exploitation attempts in real-time.