A2A Java SDK EUVD-2026-105044

Exploitation requires all of the following: (1) push notifications enabled so that createTaskPushNotificationConfiguration routes requests to RestHandler.parseRequestBody; (2) an authenticated request (PR:L) to /v1/tenants/{tenant}/tasks/{taskId}/pushNotificationConfigs carrying token and/or authentication.credentials values; (3) a request body that is valid JSON but fails protobuf deserialization - e.g. an unknown field under strict parsing or a schema mismatch - to reach the Level.SEVERE log call; and (4) read access to the server logs or the log-aggregation/SIEM system where those logs are shipped. Limiting factors: the secret only leaks if a client actually supplies push credentials, the push-notification feature must be enabled, the actor retrieving the secret needs log access rather than network access, and only versions strictly prior to 1.3.0.Final are affected.

This is a genuine but moderate-severity information-disclosure issue (CWE-532), not a high-urgency code-execution class flaw. The vendor CVSS 4.0 vector (AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N) correctly models a confidentiality-only impact gated behind several conditions: local-equivalent access to the server logs (AV:L), an authenticated request (PR:L), the push-notification feature being enabled, and a parse-failure attack requirement (AT:P). The signals are internally consistent - there is no network-vs-local conflict, because the sensitive data is realized only once an actor can read the logs, so AV:L is appropriate rather than a contradiction. No EPSS score, CISA KEV listing, or public POC was provided in the input, so per the precision rules this is 'no public exploit identified at time of analysis.' Because EPSS/KEV data is absent, widespread automated exploitation cannot be assessed from the available signals; practical risk is driven by who can read the server logs or log-aggregation system rather than by internet-facing attack surface. Overall this is a 'fix on normal patch cadence' item: real (bearer tokens and credentials leak in cleartext and can be reused to forge push callbacks) but materially constrained by the log-access and feature-enablement prerequisites.

In a deployment with push notifications enabled, a client (or an authenticated actor) sends a push-notification-config request whose JSON is valid but fails protobuf deserialization (for example by including an unknown field under strict parsing). The server logs the entire request body at SEVERE level, writing the token and authentication.credentials in cleartext. A separate actor with read access to the server logs or the log-aggregation system then harvests those credentials and uses them to send forged task-status updates to the client's push-notification endpoint. No public exploit code was identified at the time of analysis.