CVE-2026-113704 in a2a-rs
Summary
by MITRE • 10/21/2026
A vulnerability has been found in a2aproject a2a-rs up to 0.4.3. This affects the function HttpPushSender of the file crates/server/src/push_notification_sender.rs of the component Push Notification Handler. Such manipulation of the argument TaskPushNotificationConfig leads to server-side request forgery. The attack may be launched remotely. The name of the patch is 2ba50176ea9f222d9a7d0f0e8cfe6fae7cf4c224. Applying a patch is advised to resolve this issue.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/21/2026
The vulnerability identified in the a2aproject a2a-rs library, specifically affecting versions up to 0.4.3, represents a critical server-side request forgery flaw within its push notification handling subsystem. This security defect resides in the HttpPushSender function located in the crates/server/src/push_notification_sender.rs file. The core issue stems from insufficient validation of user-supplied input passed through the TaskPushNotificationConfig argument structure. When an attacker provides maliciously crafted data for this configuration, they can manipulate the internal HTTP client to initiate requests to arbitrary destinations controlled by the adversary rather than the intended notification endpoint. This lack of strict output encoding or destination allowlisting allows the server to act as a proxy for unauthorized network connections, effectively bypassing local security controls and firewall rules that might otherwise restrict outbound traffic from specific services.
From an operational perspective, this vulnerability enables remote attackers to exploit the application's trust in its own configuration mechanisms. By leveraging the HttpPushSender function, an attacker can force the vulnerable server to send HTTP requests to internal network resources, such as cloud metadata endpoints or private API servers that are not exposed to the public internet. This capability facilitates a range of malicious activities including data exfiltration from internal systems, reconnaissance of the underlying infrastructure by mapping out accessible services, and potentially chaining this flaw with other vulnerabilities to achieve remote code execution if certain deserialization or injection points exist in the target endpoints. The attack vector is classified as remote because it can be triggered over the network without requiring prior authentication or local access, making it particularly dangerous for applications deployed in cloud environments where internal service discovery relies on predictable metadata URLs.
This flaw aligns with CWE-918 Server-Side Request Forgery (SSRF), which describes weaknesses that allow an attacker to cause the server-side application to make requests to a destination unintended by the user. In the context of modern web architectures, SSRF is often categorized under MITRE ATT&CK technique T1557, specifically Adversary-in-the-Middle or Lateral Tool Transfer when used to pivot through compromised hosts. The absence of rigorous validation on the TaskPushNotificationConfig parameters means that any component accepting push notification configurations becomes a potential entry point for this attack. This is particularly relevant in microservices architectures where inter-service communication relies heavily on automated configuration, as it undermines the principle of least privilege by allowing one service to interact with others without explicit authorization checks at the network level.
To mitigate this vulnerability, immediate action should be taken to apply the patch identified by commit hash 2ba50176ea9f222d9a7d0f0e8cfe6fae7cf4c224, which addresses the input validation logic within the HttpPushSender function. Beyond applying the update, organizations should implement defense-in-depth strategies such as network segmentation to isolate services that handle push notifications from sensitive internal resources. Additionally, implementing strict allowlists for outbound HTTP requests at the application level or using a dedicated egress proxy with URL filtering can prevent exploitation even if similar vulnerabilities are discovered in future versions. It is also advisable to audit other areas of the codebase where external URLs are constructed dynamically to ensure consistent security practices across all network-facing components.