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.

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.

Impact. Push notification bearer tokens and authentication credentials submitted by clients are written to server log files in cleartext. Any operator, log aggregation system, or attacker with log access can read these secrets and use them to authenticate to the client's push notification endpoints, potentially sending forged task status updates.

Where. transport/rest/src/main/java/org/a2aproject/sdk/transport/rest/handler/RestHandler.java:676 in parseRequestBody

What. The parseRequestBody method logs the entire JSON request body at SEVERE level when JsonFormat.parser().merge() throws InvalidProtocolBufferException. This method is called from createTaskPushNotificationConfiguration (line 377), where the body contains client-supplied push notification bearer tokens (field token) and authentication credentials (field authentication.credentials). These secrets are written to server log files in full.

Exploit scenario. A client creates a push notification configuration by POSTing to /v1/tenants/{tenant}/tasks/{taskId}/pushNotificationConfigs with a body containing {"url": "https://client.example.com/webhook", "token": "secret-bearer-token", "authentication": {"scheme": "Bearer", "credentials": "oauth-access-token"}, "extraField": "value"}. The extra field causes JsonFormat.parser().merge() to throw InvalidProtocolBufferException. The entire body including secret-bearer-token and oauth-access-token is logged at SEVERE level. An attacker with log access retrieves the cleartext credentials.

Preconditions. - Attacker must have access to server log files (centralized logging, log aggregation, shared infrastructure, or insider access) - Push notification capability must be enabled - A request body must fail protobuf deserialization while being valid JSON (unknown fields with strict parsing, schema mismatches)

Fix. Do not log the raw request body. Log only a sanitized summary — body length and content type, not content. Replace the log call with something like: log.log(Level.SEVERE, "Error parsing JSON request body (length={0})", body != null ? body.length() : 0).

Verification. 3/3 lens verifiers confirmed.