CVE-2026-111765

A2A Java SDK is the official Java SDK for the Agent2Agent (A2A) Protocol. Starting in version 1.3.0.Final and prior to version 1.3.2.Final, the AndroidA2AHttpClient synchronous POST path overrides the disabled-redirect setting in AndroidA2AHttpClient.createConnection() with the PostBuilder default followRedirects value of true, leaving a residual of the earlier credential-redirect fix. JSONRPCTransport and RestTransport add interceptor-produced authentication headers and call synchronous post() without disabling redirects. AuthInterceptor permits X-API-Key, API-Key, X-Auth-Token, and X-Authentication headers; Android's repackaged OkHttp strips Authorization on cross-authority redirects but retains these nonstandard headers, disclosing a complete configured API key or token to another authority. The additional exposure applies when redirect or front-door behavior is compromised separately from the credential-handling component, or those components operate in different trust domains; a completely malicious initial origin already receives the credential on the first request. Autonomous clients require no human action, while user-invoked workflows can require interaction. Explicit followRedirects(false) prevents the redirected request. The demonstrated impact is credential disclosure, not subsequent credential use, integrity or availability impact, code execution, or host compromise. This issue is fixed in version 1.3.2.Final.

A2A Java SDK is the official Java SDK for the Agent2Agent (A2A) Protocol. Starting in version 1.3.0.Final and prior to version 1.3.2.Final, the AndroidA2AHttpClient synchronous POST path overrides the disabled-redirect setting in AndroidA2AHttpClient.createConnection() with the PostBuilder default followRedirects value of true, leaving a residual of the earlier credential-redirect fix. JSONRPCTransport and RestTransport add interceptor-produced authentication headers and call synchronous post() without disabling redirects. AuthInterceptor permits X-API-Key, API-Key, X-Auth-Token, and X-Authentication headers; Android's repackaged OkHttp strips Authorization on cross-authority redirects but retains these nonstandard headers, disclosing a complete configured API key or token to another authority. The additional exposure applies when redirect or front-door behavior is compromised separately from the credential-handling component, or those components operate in different trust domains; a completely malicious initial origin already receives the credential on the first request. Autonomous clients require no human action, while user-invoked workflows can require interaction. Explicit followRedirects(false) prevents the redirected request. The demonstrated impact is credential disclosure, not subsequent credential use, integrity or availability impact, code execution, or host compromise. This issue is fixed in version 1.3.2.Final.

The GHSA-9rhm fix added this safe setting in AndroidA2AHttpClient.createConnection():

connection.setInstanceFollowRedirects(false);

The synchronous POST builder later overwrites it:

private boolean followRedirects = true;

public A2AHttpResponse post() throws IOException {
    HttpURLConnection connection = createConnection("POST", false);
    connection.setInstanceFollowRedirects(followRedirects);
    // ...
}

The second assignment wins. JSONRPCTransport and RestTransport both add interceptor-produced headers and call synchronous post() without setting followRedirects(false).

On Android's repackaged OkHttp implementation, a cross-authority redirect strips Authorization but retains nonstandard request headers. AuthInterceptor permits four nonstandard authentication header names:

X-API-Key
API-Key
X-Auth-Token
X-Authentication

I confirmed that the exact v1.3.1.Final Maven artifact forwards complete synthetic values under all four names to a second loopback authority. I also reproduced the supported AuthInterceptor to Android POST path. Explicitly calling followRedirects(false) returns the original 302 and produces no request to the collector.

All test traffic stayed on two ephemeral 127.0.0.1 listeners. All credentials were synthetic FULCRUM-SYNTHETIC-* values.

Reproduction

I have attached AndroidA2AHttpClientRedirectTest.java. Copy it to:

extras/http-client-android/src/test/java/org/a2aproject/sdk/client/http/android/

Run:

mvn -pl extras/http-client-android -am \
  -Dtest=AndroidA2AHttpClientRedirectTest \
  -Dsurefire.failIfNoSpecifiedTests=false test

On unpatched current main, the default test fails with:

Android synchronous POST must retain the documented no-redirect default
expected: <302> but was: <200>

The explicit followRedirects(true) control still passes.

The separate exact-artifact fixture passed three consecutive runs. Its relevant output was:

default status=200 x-api-key=FULCRUM-SYNTHETIC-DIRECT

authorization=null method=GET control-followRedirects-false status=302 collectorHits=0 interceptor-chain status=200 x-api-key=FULCRUM-SYNTHETIC-INTERCEPTOR collectorHits=1 header-matrix name=X-API-Key forwarded=FULCRUM-SYNTHETIC-X-API-Key header-matrix name=API-Key forwarded=FULCRUM-SYNTHETIC-API-Key header-matrix name=X-Auth-Token forwarded=FULCRUM-SYNTHETIC-X-Auth-Token header-matrix name=X-Authentication forwarded=FULCRUM-SYNTHETIC-X-Authentication

Impact and limitations

The demonstrated impact is disclosure of a complete API key or authentication token to a different authority. I am not claiming subsequent use of the credential, integrity impact, availability impact, code execution, or host compromise.

A fully malicious origin already receives the credential on the first request. The additional boundary matters most when redirect or front-door behavior is compromised separately from the component that handles request credentials, or when different parts of the origin operate in different trust domains.

The 7.5 score applies to an autonomous client where no human action is needed after the remote endpoint returns the redirect. If the Android workflow requires a person to select or invoke the remote agent, UI:R gives a 6.5 score. I have kept both vectors because that deployment detail affects severity but not the underlying behavior. These are suggested scores, consistent with the policy's statement that actual CVSS depends on the specific deployment context. The same policy labels the parent credential-redirect property as moderate.

Scope and prior art

This path appears to fall directly under the project's current security model:

1. extras/http-client-android and the client transports are listed as in scope.
2. Remote AgentCard and response data are treated as attacker-relevant inputs.
3. A malicious or compromised remote agent is part of the client-side adversary model.
4. Section 8 says automatic…

A2A Java SDK is the official Java SDK for the Agent2Agent (A2A) Protocol. Starting in version 1.3.0.Final and prior to version 1.3.2.Final, the AndroidA2AHttpClient synchronous POST path overrides the disabled-redirect setting in AndroidA2AHttpClient.createConnection() with the PostBuilder default followRedirects value of true, leaving a residual of the earlier credential-redirect fix. JSONRPCTransport and RestTransport add interceptor-produced authentication headers and call synchronous post() without disabling redirects. AuthInterceptor permits X-API-Key, API-Key, X-Auth-Token, and X-Authentication headers; Android's repackaged OkHttp strips Authorization on cross-authority redirects but retains these nonstandard headers, disclosing a complete configured API key or token to another authority. The additional exposure applies when redirect or front-door behavior is compromised separately from the credential-handling component, or those components operate in different trust domains; a completely malicious initial origin already receives the credential on the first request. Autonomous clients require no human action, while user-invoked workflows can require interaction. Explicit followRedirects(false) prevents the redirected request. The demonstrated impact is credential disclosure, not subsequent credential use, integrity or availability impact, code execution, or host compromise. This issue is fixed in version 1.3.2.Final.

A2A Java SDK is the official Java SDK for the Agent2Agent (A2A) Protocol. Starting in version 1.3.0.Final and prior to version 1.3.2.Final, the AndroidA2AHttpClient synchronous POST path overrides the disabled-redirect setting in AndroidA2AHttpClient.createConnection() with the PostBuilder default followRedirects value of true, leaving a residual of the earlier credential-redirect fix. JSONRPCTransport and RestTransport add interceptor-produced authentication headers and call synchronous post() without disabling redirects. AuthInterceptor permits X-API-Key, API-Key, X-Auth-Token, and X-Authentication headers; Android's repackaged OkHttp strips Authorization on cross-authority redirects but retains these nonstandard headers, disclosing a complete configured API key or token to another authority. The additional exposure applies when redirect or front-door behavior is compromised separately from the credential-handling component, or those components operate in different trust domains; a completely malicious initial origin already receives the credential on the first request. Autonomous clients require no human action, while user-invoked workflows can require interaction. Explicit followRedirects(false) prevents the redirected request. The demonstrated impact is credential disclosure, not subsequent credential use, integrity or availability impact, code execution, or host compromise. This issue is fixed in version 1.3.2.Final.

The GHSA-9rhm fix added this safe setting in AndroidA2AHttpClient.createConnection():

connection.setInstanceFollowRedirects(false);

The synchronous POST builder later overwrites it:

private boolean followRedirects = true;

public A2AHttpResponse post() throws IOException {
    HttpURLConnection connection = createConnection("POST", false);
    connection.setInstanceFollowRedirects(followRedirects);
    // ...
}

The second assignment wins. JSONRPCTransport and RestTransport both add interceptor-produced headers and call synchronous post() without setting followRedirects(false).

On Android's repackaged OkHttp implementation, a cross-authority redirect strips Authorization but retains nonstandard request headers. AuthInterceptor permits four nonstandard authentication header names:

X-API-Key
API-Key
X-Auth-Token
X-Authentication

I confirmed that the exact v1.3.1.Final Maven artifact forwards complete synthetic values under all four names to a second loopback authority. I also reproduced the supported AuthInterceptor to Android POST path. Explicitly calling followRedirects(false) returns the original 302 and produces no request to the collector.

All test traffic stayed on two ephemeral 127.0.0.1 listeners. All credentials were synthetic FULCRUM-SYNTHETIC-* values.

Reproduction

I have attached AndroidA2AHttpClientRedirectTest.java. Copy it to:

extras/http-client-android/src/test/java/org/a2aproject/sdk/client/http/android/

Run:

mvn -pl extras/http-client-android -am \
  -Dtest=AndroidA2AHttpClientRedirectTest \
  -Dsurefire.failIfNoSpecifiedTests=false test

On unpatched current main, the default test fails with:

Android synchronous POST must retain the documented no-redirect default
expected: <302> but was: <200>

The explicit followRedirects(true) control still passes.

The separate exact-artifact fixture passed three consecutive runs. Its relevant output was:

default status=200 x-api-key=FULCRUM-SYNTHETIC-DIRECT

authorization=null method=GET control-followRedirects-false status=302 collectorHits=0 interceptor-chain status=200 x-api-key=FULCRUM-SYNTHETIC-INTERCEPTOR collectorHits=1 header-matrix name=X-API-Key forwarded=FULCRUM-SYNTHETIC-X-API-Key header-matrix name=API-Key forwarded=FULCRUM-SYNTHETIC-API-Key header-matrix name=X-Auth-Token forwarded=FULCRUM-SYNTHETIC-X-Auth-Token header-matrix name=X-Authentication forwarded=FULCRUM-SYNTHETIC-X-Authentication

Impact and limitations

The demonstrated impact is disclosure of a complete API key or authentication token to a different authority. I am not claiming subsequent use of the credential, integrity impact, availability impact, code execution, or host compromise.

A fully malicious origin already receives the credential on the first request. The additional boundary matters most when redirect or front-door behavior is compromised separately from the component that handles request credentials, or when different parts of the origin operate in different trust domains.

The 7.5 score applies to an autonomous client where no human action is needed after the remote endpoint returns the redirect. If the Android workflow requires a person to select or invoke the remote agent, UI:R gives a 6.5 score. I have kept both vectors because that deployment detail affects severity but not the underlying behavior. These are suggested scores, consistent with the policy's statement that actual CVSS depends on the specific deployment context. The same policy labels the parent credential-redirect property as moderate.

Scope and prior art

This path appears to fall directly under the project's current security model:

1. extras/http-client-android and the client transports are listed as in scope.
2. Remote AgentCard and response data are treated as attacker-relevant inputs.
3. A malicious or compromised remote agent is part of the client-side adversary model.
4. Section 8 says automatic…