Threat database

CVE-2026-113707 is a medium severity race condition vulnerability in the a2aproject a2a-rs software, specifically in the InMemoryTaskStore::update function within a2a-server/src/task_store/inmemory.rs. It affects versions 0.4.0 through 0.4.4. The flaw can be exploited remotely and may lead to inconsistent or unintended behavior due to concurrent access. A patch identified by commit 7050c7d329238539424ee46440e23b91c4825bee is available to fix this issue.

CVE-2026-113706 is an information disclosure vulnerability in the a2aproject a2a-rs software up to version 0.4.3. The issue arises from manipulation of the argument historyLength in a function within the file a2a-server/src/task_store/inmemory.rs. This vulnerability can be exploited remotely and may lead to unauthorized information disclosure. A patch identified by commit 68f1b7e772ae5d6c9e581ac9b48bcddd10fe70eb is recommended to fix the issue.

CVE-2026-113705 is a medium severity vulnerability in a2aproject a2a-rs versions 0.4.0 through 0.4.3. It involves information exposure through error messages in the file a2a-server/src/error.rs. The vulnerability can be exploited remotely without authentication. A patch identified by commit 713b943af94ab2d521d483b841618b97a2e78a4d is available to remediate this issue.

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.

A2A Java SDK is the official Java SDK for the Agent2Agent (A2A) Protocol. Starting in version 1.3.0.Final and prior to version 1.3.2.Final, the AndroidA2AHttpClient synchronous POST path overrides the disabled-redirect setting in AndroidA2AHttpClient.createConnection() with the PostBuilder default followRedirects value of true, leaving a residual of the earlier credential-redirect fix. JSONRPCTransport and RestTransport add interceptor-produced authentication headers and call synchronous post() without disabling redirects. AuthInterceptor permits X-API-Key, API-Key, X-Auth-Token, and X-Authentication headers; Android's repackaged OkHttp strips Authorization on cross-authority redirects but retains these nonstandard headers, disclosing a complete configured API key or token to another authority. The additional exposure applies when redirect or front-door behavior is compromised separately from the credential-handling component, or those components operate in different trust domains; a completely malicious initial origin already receives the credential on the first request. Autonomous clients require no human action, while user-invoked workflows can require interaction. Explicit followRedirects(false) prevents the redirected request. The demonstrated impact is credential disclosure, not subsequent credential use, integrity or availability impact, code execution, or host compromise. This issue is fixed in version 1.3.2.Final.

Draft text for GHSA-qw47-mcm5-934w. The body below drops into the GitHub advisory description field; the metadata block maps to the form fields. Set the patched version at release; publish when the fix ships._ --- - **Ecosystem:** Maven - **Affected package:** `org.a2aproject.sdk:a2a-java-sdk-server-common` (task store / authorization) - **Affected versions:** `<= 1.2.0.Final` (and `1.2.1.Final-SNAPSHOT` on `main` prior to the fix) - **Patched version:** _(the release that carries the fix, e.g. 1.2.1.Final)_ - **CWE:** CWE-1188 (Insecure Default Initialization), CWE-862 (Missing Authorization) - **Severity:** High - **CVSS v3.1:** `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N` (7.5, High) --- ## Details The default task store performs no authorization on task reads. `InMemoryTaskStore`'s no-arg constructor sets `authorizationProvider = null`, and `InMemoryTaskStore.get(String taskId)` is a bare map lookup with no authorization check regardless of provider: ```java public InMemoryTaskStore() { this.authorizationProvider = null; // default wiring } @Override public @Nullable Task get(String taskId) { return tasks.get(taskId); // no owner / caller check } ``` Authorization is enforced only when the application both supplies a `TaskAuthorizationProvider` *and* routes requests through `AuthorizationRequestHandlerDecorator` (via CDI), which checks ownership before delegating. A server that uses the default store, or wires `DefaultRequestHandler.builder().build()` manually, or integrates through a non-CDI stack (e.g. Spring), never reaches that check. The safe posture is therefore opt-in and the shipped default is the unsafe one. A caller can read a task created by another caller simply by knowing or guessing its id. ## Summary With the SDK's default configuration, task reads are not authorized: any caller can retrieve a task (including its status, context, message history, and artifacts) created by another caller, by supplying the task id. ## PoC Using only the real production classes wired the default way (no mocks): 1. Construct the default store: `InMemoryTaskStore store = new InMemoryTaskStore();` (no-arg constructor, so no authorization provider). 2. As one caller, save a task: `store.save(victimTask, false);` with id `victim-task-42`. 3. As a second, unrelated caller with no auth context, read it back: `store.get("victim-task-42")`. The second caller receives the first caller's task in full, with no authorization check: ``` unauthenticated get(victim-task-42) returned task owned by nobody-checked: victim-task-42 / ctx=victim-ctx ``` Verified on `main` (commit `72d220c`, JDK 21) and reproduces unchanged on `1.2.0.Final`. ## Impact Task data crosses caller boundaries with no authorization. In any multi-caller deployment built on the default wiring, one caller can enumerate and read another caller's tasks, including task status, context id, the message history, and any artifacts the task carries, which for agent workloads is frequently sensitive input and generated content. Because the insecure behaviour is the default rather than a misconfiguration, it is easy to ship unintentionally, and in the default/reference deployment the transport endpoints are served without authentication enforced, so the read is reachable by an unauthenticated caller (`PR:N`). CVSS is scored against the default configuration as shipped. ## Remediation Fail closed by default: deny task reads when no authorization provider is configured, rather than treating a missing provider as allow-all, and apply the authorization check in the store's `get` path (not only in `list` and the CDI decorator) so it holds regardless of how the handler is wired. If the current permissive default is retained for single-user/testing scenarios, emit a prominent startup warning when the server comes up with no authorization provider so it cannot be shipped by accident. ## Workarounds Until a fixed release, configure a `TaskAuthorizationProvider` and ensure requests are routed through the authorization decorator (CDI wiring), rather than relying on the default no-arg store or a manually built handler. ## References - CWE-1188: Insecure Default Initialization of Resource: https://cwe.mitre.org/data/definitions/1188.html - CWE-862: Missing Authorization: https://cwe.mitre.org/data/definitions/862.html

A2A Java SDK is the official Java SDK for the Agent2Agent (A2A) Protocol. Prior to 1.3.0.Final, a malicious or compromised remote agent can cause the default JDK-based client to forward a configured API key to a third-party server. When a client application configures credentials through `CredentialService`, `AuthInterceptor.intercept` in `client/transport/spi/src/main/java/org/a2aproject/sdk/client/transport/spi/interceptors/auth/AuthInterceptor.java` uses `APIKeySecurityScheme.name()` from the remote AgentCard directly as the HTTP header name containing the credential, without checking that the declared location is HEADER. JdkA2AHttpClient uses followRedirects(NORMAL), so an agent-controlled cross-origin redirect forwards the custom credential-bearing header even when the standard Authorization header is stripped. The attack requires configured API key credentials for the agent's security scheme and control of the agent's AgentCard and redirect response, but no additional client privileges. This issue is fixed in version 1.3.0.Final.

### *Impact.** Push notification bearer tokens and authentication credentials submitted by clients are written to server log files in cleartext. Any operator, log aggregation system, or attacker with log access can read these secrets and use them to authenticate to the client's push notification endpoints, potentially sending forged task status updates. **Where.** `transport/rest/src/main/java/org/a2aproject/sdk/transport/rest/handler/RestHandler.java:676` in `parseRequestBody` **What.** The `parseRequestBody` method logs the entire JSON request body at `SEVERE` level when `JsonFormat.parser().merge()` throws `InvalidProtocolBufferException`. This method is called from `createTaskPushNotificationConfiguration` (line 377), where the body contains client-supplied push notification bearer tokens (field `token`) and authentication credentials (field `authentication.credentials`). These secrets are written to server log files in full. **Exploit scenario.** A client creates a push notification configuration by POSTing to `/v1/tenants/{tenant}/tasks/{taskId}/pushNotificationConfigs` with a body containing `{"url": "https://client.example.com/webhook", "token": "secret-bearer-token", "authentication": {"scheme": "Bearer", "credentials": "oauth-access-token"}, "extraField": "value"}`. The extra field causes `JsonFormat.parser().merge()` to throw `InvalidProtocolBufferException`. The entire body including `secret-bearer-token` and `oauth-access-token` is logged at SEVERE level. An attacker with log access retrieves the cleartext credentials. **Preconditions.** - Attacker must have access to server log files (centralized logging, log aggregation, shared infrastructure, or insider access) - Push notification capability must be enabled - A request body must fail protobuf deserialization while being valid JSON (unknown fields with strict parsing, schema mismatches) **Fix.** Do not log the raw request body. Log only a sanitized summary — body length and content type, not content. Replace the log call with something like: `log.log(Level.SEVERE, "Error parsing JSON request body (length={0})", body != null ? body.length() : 0)`. **Verification.** 3/3 lens verifiers confirmed.

A2A Java SDK is the official Java SDK for the Agent2Agent (A2A) Protocol. Prior to 1.3.0.Final, BasePushNotificationSender in server-common sends task data to the URL in TaskPushNotificationConfig without destination validation, scheme restrictions, or bounds on redirects. InMemoryPushNotificationConfigStore.setInfo stores the URL verbatim, and onCreateTaskPushNotificationConfig does not validate the destination. In the default deployment with push notifications enabled, an unauthenticated caller can register a destination through an inline SendMessage configuration or CreateTaskPushNotificationConfig for an existing task, causing task status and artifact updates to send requests from the server's network position to loopback, private, link-local cloud-metadata, IPv6 unique-local, unspecified, or multicast destinations where routing permits. JdkA2AHttpClient and VertxA2AHttpClient follow redirects, allowing a webhook redirect to bypass creation-time destination checks and convert a POST into a GET; hostname-only checks also do not prevent DNS rebinding. Direct POST delivery can push attacker-influenced task data into internal services, whereas a redirected POST-to-GET request drops the body. The sender discards the fetched response and does not expose delivery success or failure, so the demonstrated behavior does not provide response read-back. No credentials or user interaction are required. This issue is fixed in version 1.3.0.Final.

A security vulnerability has been detected in a2aproject a2a-java 1.2.0. The impacted element is the function AuthorizationRequestHandlerDecorator.onListTasks of the file server-common/src/main/java/org/a2aproject/sdk/server/requesthandlers/AuthorizationRequestHandlerDecorator.java. Such manipulation leads to missing authorization. The attack can be launched remotely. Upgrading to version 1.3.0 is sufficient to resolve this issue. The name of the patch is e9a1abf9c90c02b16d17293afdc3cc2f555d63a6. The affected component should be upgraded.

A weakness has been identified in a2aproject a2a-java 1.2.0. The affected element is the function BasePushNotificationSender.dispatchNotification of the file server-common/src/main/java/org/a2aproject/sdk/server/tasks/BasePushNotificationSender.java of the component Authorization Header Construction. This manipulation causes http response splitting. The attack can be initiated remotely. Upgrading to version 1.3.0 is sufficient to fix this issue. Patch name: 247a655043f145f6f8e3853724b6a543eaa02001. You should upgrade the affected component.

A security vulnerability has been detected in a2aproject a2a-python up to 1.1.3. This affects the function _dispatch_notification of the file src/a2a/server/tasks/base_push_notification_sender.py of the component Push Notification Sender. The manipulation of the argument push_info.url leads to server-side request forgery. Remote exploitation of the attack is possible. Upgrading to version 1.1.4 is able to mitigate this issue. It is suggested to upgrade the affected component.