--- id: "CVE-2026-111765" kind: "vulnerability" aliases: ["CVE-2026-111765", "GHSA-4fpj-g9jf-9rgg"] title: "A2A Java SDK: Android synchronous POST forwards credentials across authorities after incomplete redirect fix" severity: "high" cvss: 7.5 epss: 0.006750000175088644 exploited: false status: "open" category: "ai-tooling" products: [{"name": "org.a2aproject.sdk:a2a-java-sdk-http-client-android", "fixed": ["1.3.2.Final"], "affected": ">= 1.3.0.Final, <= 1.3.1.Final", "ecosystem": "maven"}] ecosystems: ["maven"] tags: ["a2a-java", "ai-agents", "ai-tooling", "android", "cwe-522", "java", "maven"] not_affected_if: ["managed-hosting", "no-auth-header-configured", "non-android-client"] published_at: "2026-10-20T16:17:00+00:00" first_seen_at: "2026-10-23T19:11:32+00:00" updated_at: "2026-10-23T21:57:20+00:00" sources: [{"source": "ghsa", "url": "https://github.com/advisories/GHSA-4fpj-g9jf-9rgg", "first_seen_at": "2026-10-23T19:11:32+00:00"}, {"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-111765", "first_seen_at": "2026-10-23T21:57:20+00:00"}] --- # A2A Java SDK: Android synchronous POST forwards credentials across authorities after incomplete redirect fix The A2A Java SDK's Android synchronous POST path re-enables automatic redirects, so a cross-authority redirect resends API keys or auth tokens to another host. An attacker who controls or sits in front of the remote agent endpoint gets the complete credential value in an allowed header such as X-API-Key or X-Auth-Token. _Summary, check and fix written by a model from the sources; labelled as such._ ## Affected - maven:org.a2aproject.sdk:a2a-java-sdk-http-client-android affected >= 1.3.0.Final, <= 1.3.1.Final fixed 1.3.2.Final ## How to check Check the Maven dependency for org.a2aproject.sdk:a2a-java-sdk-http-client-android; versions 1.3.0.Final through 1.3.1.Final are affected. Search the project for AndroidA2AHttpClient and the followRedirects field; it is affected if the field defaults to true. ## Fix Upgrade org.a2aproject.sdk:a2a-java-sdk-http-client-android to 1.3.2.Final. Until upgraded, call followRedirects(false) on synchronous POST requests. ## Timeline - 2026-10-23T19:11:32+00:00 ghsa https://github.com/advisories/GHSA-4fpj-g9jf-9rgg - 2026-10-23T21:57:20+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-111765 ## From the sources 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 redirects are disabled in all JDK, Vert.x, and Android implementations to prevent credential leakage. 5. Section 13 defines a violation of a Section 8 property through the covered input and adversary as VALID. 6. Section 13a lists missed call sites and under-strength mitigations as new findings after an incomplete fix. 7. 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. Suggested fix 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. 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 --- _Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_