Threat Intelligence Database

### *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.

The GHSA-9rhm fix added this safe setting in AndroidA2AHttpClient.createConnection(): connection.setInstanceFollowRedirects(false); The synchronous POST builder later overwrites it: private boolean followRedirects = true; public A2AHttpResponse post() throws IOException { HttpURLConnection connection = createConnection("POST", false); connection.setInstanceFollowRedirects(followRedirects); // ... } The second assignment wins. JSONRPCTransport and RestTransport both add interceptor-produced headers and call synchronous post() without setting followRedirects(false). On Android's repackaged OkHttp implementation, a cross-authority redirect strips Authorization but retains nonstandard request headers. AuthInterceptor permits four nonstandard authentication header names: X-API-Key API-Key X-Auth-Token X-Authentication I confirmed that the exact v1.3.1.Final Maven artifact forwards complete synthetic values under all four names to a second loopback authority. I also reproduced the supported AuthInterceptor to Android POST path. Explicitly calling followRedirects(false) returns the original 302 and produces no request to the collector. All test traffic stayed on two ephemeral 127.0.0.1 listeners. All credentials were synthetic FULCRUM-SYNTHETIC-* values. Reproduction I have attached AndroidA2AHttpClientRedirectTest.java. Copy it to: extras/http-client-android/src/test/java/org/a2aproject/sdk/client/http/android/ Run: mvn -pl extras/http-client-android -am \ -Dtest=AndroidA2AHttpClientRedirectTest \ -Dsurefire.failIfNoSpecifiedTests=false test On unpatched current main, the default test fails with: Android synchronous POST must retain the documented no-redirect default expected: <302> but was: <200> The explicit followRedirects(true) control still passes. The separate exact-artifact fixture passed three consecutive runs. Its relevant output was: default status=200 x-api-key=FULCRUM-SYNTHETIC-DIRECT authorization=null method=GET control-followRedirects-false status=302 collectorHits=0 interceptor-chain status=200 x-api-key=FULCRUM-SYNTHETIC-INTERCEPTOR collectorHits=1 header-matrix name=X-API-Key forwarded=FULCRUM-SYNTHETIC-X-API-Key header-matrix name=API-Key forwarded=FULCRUM-SYNTHETIC-API-Key header-matrix name=X-Auth-Token forwarded=FULCRUM-SYNTHETIC-X-Auth-Token header-matrix name=X-Authentication forwarded=FULCRUM-SYNTHETIC-X-Authentication Impact and limitations The demonstrated impact is disclosure of a complete API key or authentication token to a different authority. I am not claiming subsequent use of the credential, integrity impact, availability impact, code execution, or host compromise. A fully malicious origin already receives the credential on the first request. The additional boundary matters most when redirect or front-door behavior is compromised separately from the component that handles request credentials, or when different parts of the origin operate in different trust domains. The 7.5 score applies to an autonomous client where no human action is needed after the remote endpoint returns the redirect. If the Android workflow requires a person to select or invoke the remote agent, UI:R gives a 6.5 score. I have kept both vectors because that deployment detail affects severity but not the underlying behavior. These are suggested scores, consistent with the policy's statement that actual CVSS depends on the specific deployment context. The same policy labels the parent credential-redirect property as moderate. Scope and prior art This path appears to fall directly under the project's current security model: 1. extras/http-client-android and the client transports are listed as in scope. 2. Remote AgentCard and response data are treated as attacker-relevant inputs. 3. A malicious or compromised remote agent is part of the client-side adversary model. 4. Section 8 says automatic redirects are disabled in all JDK, Vert.x, and Android implementations to prevent credential leakage. 5. Section 13 defines a violation of a Section 8 property through the covered input and adversary as VALID. 6. Section 13a lists missed call sites and under-strength mitigations as new findings after an incomplete fix. 7. Section 14 records the original issue as fixed by disabling redirects across all HTTP client implementations. The Android synchronous path directly contradicts that recorded repair state. This report does not claim that an AgentCard SecurityScheme declaration enforces authentication. The application has already configured the credential, and the shipped AuthInterceptor places it in an allowed header. The failure is the Android client's default redirect behavior after that point. It does not depend on a custom SPI, an insecure configuration flag, a test-only component, server-side authentication, or any of the recurring non-findings listed in Section 11a. GHSA-9rhm is t

--- - **Ecosystem:** Maven - **Affected package:** `org.a2aproject.sdk:a2a-java-sdk-server-common` (push-notification delivery) - **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)_ - **CWE:** CWE-918 (Server-Side Request Forgery) - **Severity:** High - **CVSS v3.1:** `CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:L/A:N` (5.8, Moderate) --- ## Summary An **unauthenticated** attacker can coerce the a2a-java server into issuing HTTP requests to arbitrary internal and cloud-metadata endpoints from the server's own network position — a Server-Side Request Forgery reachable in the default deployment with no credentials, no user interaction, and a single request. The behaviour is the shipped default, not a misconfiguration. ## Details `BasePushNotificationSender` (in `server-common`) POSTs task data to the URL stored on a task's `TaskPushNotificationConfig` with no validation of the destination: no block on loopback, RFC1918, link-local (`169.254.0.0/16`, including the `169.254.169.254` metadata address), unique-local, unspecified, or multicast ranges; no scheme restriction; and no bound on redirects. `InMemoryPushNotificationConfigStore.setInfo` stores the URL verbatim and `onCreateTaskPushNotificationConfig` does not check it either. Both shipped HTTP clients follow redirects (`JdkA2AHttpClient` → `followRedirects(NORMAL)`, `VertxA2AHttpClient` → `setFollowRedirects(true)`), so a creation-time URL allowlist is bypassable: an attacker webhook answers `302 Location: http://169.254.169.254/...` and the client follows it. A hostname check is likewise defeated by DNS rebinding. A correct guard must validate the *resolved* IP of every hop at connection time, not the URL string. ## Exploitation Demonstrated end-to-end against a running server (default wiring, unauthenticated caller): - **Arbitrary internal reachability.** The attacker picks the destination and the server issues the request from inside the trust boundary. Delivery to loopback and to a real RFC1918 LAN address was exercised at runtime; because the code applies no destination filtering of any kind, the same path reaches link-local / metadata (`169.254.169.254`) and other internal ranges wherever network routing permits. - **Allowlist + method bypass via redirect.** A `302` from the attacker's webhook reaches destinations a creation-time allowlist would block, and a `302` on a `POST` is followed as a `GET` — so GET-only endpoints such as the IMDS credentials path are reachable even though the sender only issues `POST`s. This is why a URL allowlist is not a sufficient fix; the guard must validate the resolved IP of every redirect hop. - **Data push into internal services.** On direct (non-redirected) delivery, each request carries the task payload in the body, so internal services that ingest POST data receive attacker-influenced content (basis for `I:L`). On a redirected request the body is dropped in the POST→GET conversion, so the body-push and the redirect-reach are separate capabilities, not simultaneous on one request. The sender discards the fetched response and exposes no caller-visible difference between a successful and a failed delivery (both paths return without surfacing status or body), so the base case reads back nothing — confidentiality is scored `C:N`. Read-back is limited, reach is not: the attacker still drives fully controlled requests to metadata and internal services and writes data into them. ## PoC Against a running server with push notifications enabled (JSON-RPC transport), using only the real production classes wired the default way: 1. Start a local listener standing in for an internal target (no real metadata service is touched). 2. Send one `SendMessage` that starts a long-running task, with the push config inlined and its `url` set to `http://<internal-target>/latest/meta-data/iam/security-credentials/`. Use `returnImmediately: true`, header `A2A-Version: 1.0`, and role `ROLE_USER`. The URL is stored verbatim. (Equivalent via `CreateTaskPushNotificationConfig` on an existing task.) 3. As the task emits state/artifact updates, the sender POSTs each one to the stored URL, from the server's own network position: ``` POST /latest/meta-data/iam/security-credentials/ HTTP/1.1 Host: 169.254.169.254 Content-Type: application/json {"artifactUpdate":{"taskId":"...","artifact":{"parts":[{"text":"Progress update 1/20"}]}, ...}} ``` One `SendMessage` produced multiple server-side POSTs to the attacker-chosen internal path. Verified on `main` (commit `72d220c`, JDK 21) and unchanged on `1.2.0.Final`. ## Remediation Validate the *resolved* IP of the target and of every redirect hop before connecting: reject loopback / RFC1918 / link-local / metadata / unique-local / unspecified / multicast; restrict the scheme to `http`/`https`; cap redirects; and resolve-and-pin to defeat

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

*Impact.** A malicious or compromised A2A agent can cause the client's API key credential to be forwarded to an arbitrary third-party server. The agent serves an AgentCard with an `APIKeySecurityScheme` specifying a custom header name, then responds with an HTTP redirect. The JDK HttpClient follows the redirect and forwards the custom header containing the credential, since only the standard `Authorization` header may be stripped on cross-origin redirects. **Where.** `client/transport/spi/src/main/java/org/a2aproject/sdk/client/transport/spi/interceptors/auth/AuthInterceptor.java:69` in `intercept` **What.** The `apiKeySecurityScheme.name()` field from the remote agent's AgentCard (untrusted, server-controlled data) is used directly as the HTTP header name when placing client credentials. Combined with `JdkA2AHttpClient`'s `followRedirects(NORMAL)` policy, credentials under custom header names survive cross-origin redirects (only `Authorization` is stripped on newer JDKs), allowing a malicious agent to leak client credentials to third-party servers. Additionally, `AuthInterceptor` does not check that `location==HEADER` before placing the credential as a header. **Exploit scenario.** Client configures an API key credential for agent's security scheme `myAuth`. The malicious agent returns an AgentCard where `securitySchemes` includes `myAuth` as `APIKeySecurityScheme` with `name='X-Leaked-Cred'` and `location=HEADER`. `AuthInterceptor` places the credential in the `X-Leaked-Cred` header. The agent responds with HTTP 302 redirect to `https://evil.com/collect`. `JdkA2AHttpClient` follows the redirect, forwarding all custom headers including `X-Leaked-Cred` to `evil.com`. The attacker captures the client's credential. **Preconditions.** - Client application has configured API key credentials via `CredentialService` for the agent's security scheme - The agent is malicious or compromised (controls its own AgentCard response) - The default `JdkA2AHttpClient` is used (with `followRedirects=NORMAL`) - The JDK version does not strip custom headers on cross-origin redirects (all current versions) **Fix.** Validate the `APIKeySecurityScheme.name()` field against a whitelist of safe header names. Check that `apiKeySecurityScheme.location()` equals `Location.HEADER` before placing the credential as a header. Consider using `followRedirects(NEVER)` and implementing manual redirect handling that strips all authentication headers on cross-origin redirects. **Verification.** 2/3 lens verifiers confirmed.

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 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.