Skip to content
Vulnerabilities

Android SDK flaw leaks auth headers via redirects in A2A Java client

A high severity vulnerability in the A2A Java SDK allows authentication credentials to leak to external hosts during synchronous POST requests.

Illustration: A smartphone screen displays a web browser window with blank abstract content.
AI-generated illustration: AppSec Scoop

Key points

  • Versions 1.3.0.Final and 1.3.1.Final of org.a2aproject.sdk:a2a-java-sdk-http-client-android are affected.
  • A patch is available in version 1.3.2.Final which corrects the redirect handling logic.
  • The flaw allows nonstandard authentication headers to bypass authority stripping on redirects.

The A2A Java SDK for Android contains a high severity vulnerability that permits authentication credentials to leak to unintended destinations. The flaw affects versions 1.3.0.Final and 1.3.1.Final of the org.a2aproject.sdk:a2a-java-sdk-http-client-android package. A fix has been confirmed in version 1.3.2.Final.

What happened

The vulnerability stems from incorrect redirect handling within the AndroidA2AHttpClient component. A previous security fix introduced a setting to disable automatic redirects, but subsequent code overwrites this configuration. The synchronous POST builder explicitly sets followRedirects to true, overriding the safer default established earlier in the connection setup process.

This override affects both JSONRPCTransport and RestTransport components. These transports add interceptor-produced headers and execute synchronous POST requests without resetting the followRedirects flag to false. Consequently, the client follows redirects when it should return the original redirect response code to the application.

On Android’s repackaged OkHttp implementation, cross-authority redirects normally strip the standard Authorization header. However, the implementation retains nonstandard request headers during these redirects. The AuthInterceptor component permits four specific nonstandard authentication header names: X-API-Key, API-Key, X-Auth-Token, and X-Authentication.

Testing confirmed that version 1.3.1.Final forwards complete synthetic values under all four header names to a second loopback authority. The reproduction used ephemeral listeners on 127.0.0.1 and synthetic credentials. Explicitly calling followRedirects(false) returns the original 302 status and prevents the request from reaching the collector.

Why it matters

Organisations using the affected SDK versions risk exposing sensitive authentication tokens to third-party domains. If an application relies on nonstandard header names for authentication, those credentials may be transmitted to malicious servers during redirect chains. This bypasses standard protection mechanisms that strip standard authorization headers.

The impact is limited to applications using the synchronous POST method with these specific header configurations. Standard Authorization headers are stripped by the underlying OkHttp implementation, but custom headers remain vulnerable. This creates a specific attack vector for credential theft in Android applications using this library.

What happens next

  • Verify whether your Android applications use org.a2aproject.sdk:a2a-java-sdk-http-client-android.
  • Check the current version against the vulnerable range of 1.3.0.Final to 1.3.1.Final.
  • Update to version 1.3.2.Final to apply the confirmed patch for this redirect handling flaw.
  • Review application code for usage of nonstandard authentication headers in HTTP requests.

Patch priority

Teams should prioritise updating systems that handle sensitive authentication data via nonstandard headers. Check whether applications using this SDK interact with external services that might trigger redirects. Roll out the patch to production environments after testing in a staging environment to ensure compatibility. Back up current configurations before applying the update. Monitor network logs for unexpected redirect activity during the transition period to detect any residual exposure.

What to do and how to stay safe: A2A Java SDK

  • Audit dependencies for the specific A2A Java SDK package and version range.
  • Restrict the use of nonstandard authentication headers where possible to reduce exposure.
  • Monitor server logs for unexpected credential transmission to external domains.
  • Implement strict redirect policies in application code as a defensive measure.

Step-by-step guide: Patch Management: Definition, Purpose and Operational Reality

General security guidance from the AppSec Scoop newsroom. It is not confirmed advice from the organisations named in this story.

Frequently asked questions

Which versions of the A2A Java SDK are vulnerable?

Versions 1.3.0.Final and 1.3.1.Final of the org.a2aproject.sdk:a2a-java-sdk-http-client-android package are affected.

Is there a fix available for this vulnerability?

Yes, a patch has been released in version 1.3.2.Final which corrects the redirect handling logic.

What types of headers are leaked during the exploit?

The flaw leaks nonstandard authentication headers including X-API-Key, API-Key, X-Auth-Token, and X-Authentication.

Sources

  1. GitHub Advisory Database
A2A Java SDKCVE-2026-111765AndroidMavenGitHub

Related stories