A2A Java SDK Android Redirect Bug Exposes Custom Auth Credentials in Specific Versions
A high-severity flaw in the A2A Java SDK for Android allows custom authentication headers to leak during HTTP redirects, exposing credentials to third parties.
Key points
- Versions 1.3.0.Final and 1.3.1.Final of the a2a-java-sdk-http-client-android package are affected.
- The flaw arises because synchronous POST requests overwrite the safe no-redirect default setting.
- Four specific nonstandard authentication header names are forwarded to redirect targets.
The A2A Java SDK for Android contains a high-severity vulnerability that allows authentication credentials to be transmitted to unintended destinations. This issue affects versions 1.3.0.Final and 1.3.1.Final of the org.a2aproject.sdk:a2a-java-sdk-http-client-android package. A patched version, 1.3.2.Final, has been released to address the defect.
The risk
The vulnerability stems from how the SDK handles HTTP redirects. Although the initial connection setup disables automatic redirects, the synchronous POST builder later overwrites this setting to allow redirects. This behavior causes the client to follow cross-authority redirects. On Android’s repackaged OkHttp implementation, standard Authorization headers are stripped during such redirects. However, nonstandard request headers are retained and forwarded.
Who is exposed
Developers using the affected SDK versions who rely on custom authentication headers are exposed. The AuthInterceptor component permits four specific nonstandard header names for authentication. These include X-API-Key, API-Key, X-Auth-Token, and X-Authentication. If an application uses any of these headers, their values are sent to the redirect target.
Cost and compliance
The source material does not provide information regarding financial costs or specific compliance implications. The advisory focuses on the technical mechanics of the header leakage and the availability of the patched version.
What to watch
Security teams should verify if their Android applications use the affected SDK versions. They should also check whether their applications utilize the four nonstandard authentication header names identified in the advisory. Monitoring for unexpected outbound connections to third-party domains during login or API calls can help detect exploitation.
Signals worth monitoring
Teams usually start by reviewing proxy logs for HTTP 302 responses originating from application traffic. Check whether any requests containing sensitive headers are redirected to external domains. Look for anomalies in header retention during redirect chains. Verify that authentication tokens are not present in requests to unknown hosts. Review application logs for unexpected status code transitions. Ensure that network policies restrict outbound connections to known services. Monitor for spikes in traffic to non-authorized endpoints.
What to do and how to stay safe: A2A Java SDK
- Update the a2a-java-sdk-http-client-android package to version 1.3.2.Final or later to apply the vendor-provided fix.
- Audit application code to identify if any of the four nonstandard authentication header names are in use.
- Implement network-level restrictions to prevent applications from following redirects to untrusted domains.
- Monitor server logs for requests containing these specific headers from unexpected source IPs.
Step-by-step guide: Vulnerability Prioritization: Fix What Actually Matters First
General security guidance from the SecOps Signal newsroom. It is not confirmed advice from the organisations named in this story.
Frequently asked questions
Which versions of the A2A Java SDK are affected by this vulnerability?
Versions 1.3.0.Final and 1.3.1.Final of the a2a-java-sdk-http-client-android package are vulnerable.
Is there a fix available for this issue?
Yes, version 1.3.2.Final has been released and addresses the vulnerability.
What headers are leaked during the redirect?
The headers X-API-Key, API-Key, X-Auth-Token, and X-Authentication are forwarded to the redirect target.
