CVE-2026-111765

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-ap