CVE-2026-111762 in a2a-java
Summary
by MITRE • 10/20/2026
A2A Java SDK is the official Java SDK for the Agent2Agent (A2A) Protocol. Prior to 1.3.0.Final, RestHandler.parseRequestBody in `transport/rest/src/main/java/org/a2aproject/sdk/transport/rest/handler/RestHandler.java` logs the entire JSON request body at SEVERE level when JsonFormat.parser().merge() throws InvalidProtocolBufferException. With push notifications enabled, createTaskPushNotificationConfiguration reaches this parser for requests to `/v1/tenants/{tenant}/tasks/{taskId}/pushNotificationConfigs`, whose token and authentication.credentials fields can contain bearer tokens and authentication credentials for client push endpoints. A valid JSON body that fails protobuf deserialization, including an unknown field under strict parsing or a schema mismatch, causes those secrets to be written to the server logs in cleartext. An attacker with access to the server logs or a log aggregation system can retrieve the credentials and potentially use the credentials to send forged task status updates to the client's push notification endpoint. This issue is fixed in version 1.3.0.Final.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 10/20/2026
The A2A Java SDK serves as the official implementation for the Agent-to-Agent Protocol, facilitating secure communication between autonomous agents. Within this framework, the RestHandler component plays a critical role in processing incoming HTTP requests via REST endpoints. Specifically, the parseRequestBody method is responsible for deserializing JSON payloads into protocol buffer structures using JsonFormat.parser().merge(). In versions prior to 1.3.0.Final, a significant information disclosure vulnerability exists within this parsing logic. When the parser encounters malformed data or schema mismatches that trigger an InvalidProtocolBufferException, the error handling routine logs the entire raw request body at the SEVERE log level before propagating the exception. This design choice inadvertently exposes sensitive payload contents during normal operational errors such as strict JSON field validation failures or protobuf deserialization issues.
The vulnerability is particularly severe in the context of push notification configurations managed through the /v1/tenants/{tenant}/tasks/{taskId}/pushNotificationConfigs endpoint. When clients configure task push notifications, they must provide authentication credentials and bearer tokens within the request body to authenticate with external push service endpoints. Because these fields are included in the JSON payload that gets logged upon parsing failure, any error condition resulting from invalid input or schema mismatches results in the cleartext exposure of these high-value secrets. This includes both the static token values and dynamic authentication credentials required for client push endpoint access. The flaw represents a classic case of excessive data logging where sensitive information is retained in log files without sanitization, violating fundamental principles of secure software development regarding credential handling.
From an operational impact perspective, this vulnerability allows attackers with read access to server logs or centralized log aggregation systems to harvest valid authentication credentials and bearer tokens. These stolen secrets can be directly exploited to impersonate legitimate agents by sending forged task status updates to the victim's push notification endpoints. This capability undermines the integrity of the agent communication protocol, potentially leading to unauthorized state changes, misinformation propagation, or denial of service through malicious notifications. The attack vector is straightforward as it relies on triggering parsing errors with crafted inputs and then monitoring logs for the resulting output, requiring no complex exploitation techniques beyond basic interaction with the API endpoint.
This issue aligns with CWE-532, which covers information exposure through log files, a common vulnerability pattern in enterprise applications where debug or error logging is enabled without proper data filtering. It also relates to CWE-798, involving the use of hardcoded credentials if those tokens were static, though here it primarily concerns dynamic credential leakage via logs. In terms of MITRE ATT&CK mapping, this behavior facilitates Credential Access through techniques such as Log Collection (T1005) and potentially Account Manipulation or Command and Control abuse depending on how the stolen tokens are utilized to forge messages within the A2A protocol ecosystem.
The recommended mitigation is to upgrade immediately to version 1.3.0.Final of the A2A Java SDK, where this logging behavior has been corrected to prevent sensitive data from being written to logs during parsing exceptions. For organizations unable to patch immediately due to dependency constraints, a temporary workaround involves implementing custom error handling wrappers around the RestHandler.parseRequestBody method or configuring loggers to suppress SEVERE level messages for specific classes while maintaining visibility into other critical errors. Additionally, security teams should audit existing log storage systems for any previously leaked credentials and rotate all affected bearer tokens and authentication secrets immediately upon discovery of potential exposure. Implementing strict input validation before parsing can also reduce the frequency of these exceptions, thereby minimizing the attack surface for this information disclosure flaw.