Summary
A2A Java SDK: Android synchronous POST forwards credentials across authorities after incomplete redirect fix
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:
- extras/http-client-android and the client transports are listed as in scope.
- Remote AgentCard and response data are treated as attacker-relevant inputs.
- A malicious or compromised remote agent is part of the client-side
adversary model. - Section 8 says automatic redirects are disabled in all JDK, Vert.x,
and Android implementations to prevent credential leakage. - Section 13 defines a violation of a Section 8 property through the
covered input and adversary as VALID. - Section 13a lists missed call sites and under-strength mitigations
as new findings after an incomplete fix. - Section 14 records the original issue as fixed by disabling
redirects across all HTTP client implementations. The Android
synchronous path directly contradicts that recorded repair state.
This report does not claim that an AgentCard SecurityScheme
declaration enforces authentication. The application has already
configured the credential, and the shipped AuthInterceptor places it
in an allowed header. The failure is the Android client's default
redirect behavior after that point. It does not depend on a custom
SPI, an insecure configuration flag, a test-only component,
server-side authentication, or any of the recurring non-findings
listed in Section 11a.
GHSA-9rhm is the direct parent finding. Its fix commit says redirects
were disabled across all clients, but the Android POST-level override
remains in 1.3.0.Final, 1.3.1.Final, and current main. I searched the
public issues and pull requests on September 5 and found PR #1097, but
no report covering this surviving synchronous Android path. The other
three published advisories address server authorization defaults,
push-notification SSRF, and credential logging. They do not cover this
Android client path.
References
Security property:
https://github.com/a2aproject/a2a-java/blob/30e31086e24bea096b5f662088661269c9119100/SECURITY.md#L335-L342
Triage and incomplete-fix rules:
https://github.com/a2aproject/a2a-java/blob/30e31086e24bea096b5f662088661269c9119100/SECURITY.md#L547-L573
Android documentation:
https://github.com/a2aproject/a2a-java/blob/30e31086e24bea096b5f662088661269c9119100/docs/content/dev/security.md#L60-L74
Safe connection setting and later POST override:
https://github.com/a2aproject/a2a-java/blob/30e31086e24bea096b5f662088661269c9119100/extras/http-client-android/src/main/java/org/a2aproject/sdk/client/http/android/AndroidA2AHttpClient.java#L95-L114
https://github.com/a2aproject/a2a-java/blob/30e31086e24bea096b5f662088661269c9119100/extras/http-client-android/src/main/java/org/a2aproject/sdk/client/http/android/AndroidA2AHttpClient.java#L269-L300
AuthInterceptor allowlist and credential injection:
https://github.com/a2aproject/a2a-java/blob/30e31086e24bea096b5f662088661269c9119100/client/transport/spi/src/main/java/org/a2aproject/sdk/client/transport/spi/interceptors/auth/AuthInterceptor.java#L33-L46
https://github.com/a2aproject/a2a-java/blob/30e31086e24bea096b5f662088661269c9119100/client/transport/spi/src/main/java/org/a2aproject/sdk/client/transport/spi/interceptors/auth/AuthInterceptor.java#L85-L90
Parent advisory and fix:
https://github.com/a2aproject/a2a-java/security/advisories/GHSA-9rhm-2h4x-jwmx
https://github.com/a2aproject/a2a-java/commit/2a36530d75e11bcf9b81f543464dbe193ca6478e
Android redirect implementation:
https://android.googlesource.com/platform/external/okhttp/+/05b3c271102f7e16bd772dd8a9dab5c6b1424c24/repackaged/okhttp/src/main/java/com/android/okhttp/internal/http/HttpEngine.java#900
Impact
CVE-2026-111765 has a CVSS score of 7.5 (High). The vector is network-reachable, no privileges required, and no user interaction. A CVSS score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether this affects your application depends on whether the vulnerable code is present and reachable in your environment. A fixed version is available (1.3.2.Final); upgrading removes the vulnerable code path.
Affected versions
Security releases
Kodem intelligence
Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.
Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.
Already deployed Kodem?
See it in your environmentNew to Kodem? Get a demo →Remediation advice
The smallest compatible change is:
- private boolean followRedirects = true;
+ private boolean followRedirects = false;
This keeps followRedirects(true) available as an explicit opt-in. The
attached regression passes three out of three times after the change.
The Android module and its reactor dependencies pass 455 tests with no
failures. The full repository test run passes 2,914 tests with no
failures or errors. It reports 127 skips when using the project's
documented -DskipDockerTests=true option inside the isolated build
container.
Frequently Asked Questions
- What is CVE-2026-111765? CVE-2026-111765 is a high-severity security vulnerability in org.a2aproject.sdk:a2a-java-sdk-http-client-android (maven), affecting versions >= 1.3.0.Final, <= 1.3.1.Final. It is fixed in 1.3.2.Final.
- How severe is CVE-2026-111765? CVE-2026-111765 has a CVSS score of 7.5 (High). This score reflects the worst-case severity of the vulnerability, not your specific exposure. Whether it represents real risk in your environment depends on whether the vulnerable code is present and reachable.
- Which versions of org.a2aproject.sdk:a2a-java-sdk-http-client-android are affected by CVE-2026-111765? org.a2aproject.sdk:a2a-java-sdk-http-client-android (maven) versions >= 1.3.0.Final, <= 1.3.1.Final is affected.
- Is there a fix for CVE-2026-111765? Yes. CVE-2026-111765 is fixed in 1.3.2.Final. Upgrade to this version or later.
- Is CVE-2026-111765 exploitable, and should I be worried? Whether CVE-2026-111765 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
- What actually determines whether CVE-2026-111765 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
- How do I fix CVE-2026-111765? Upgrade
org.a2aproject.sdk:a2a-java-sdk-http-client-androidto 1.3.2.Final or later.