Veille CVE

Octobre 2026

5 CVE

  1. CVE-2026-111765 7.5 Élevée

    a2aproject a2a-java

    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.

  2. CVE-2026-111764 7.5 Élevée

    a2aproject a2a-java

    A2A Java SDK is the official Java SDK for the Agent2Agent (A2A) Protocol. Prior to 1.3.0.Final, the default InMemoryTaskStore configuration performs no authorization on task reads: the no-argument constructor sets authorizationProvider to null, and InMemoryTaskStore.get(String taskId) returns the stored task without checking the caller or owner. Authorization depends on supplying a TaskAuthorizationProvider and routing requests through AuthorizationRequestHandlerDecorator, whether installed through CDI or explicitly by the application. Default store wiring and manually constructed DefaultRequestHandler.builder().build() handlers, including integrations such as Spring, leave task reads unprotected when no effective authorization-provider and decorator check is installed. In a multi-caller deployment using the default configuration, a caller who knows or guesses another caller's task ID can retrieve the task status, context ID, message history, and artifacts. The default/reference transport endpoints do not enforce authentication, so the task-read disclosure is reachable by an unauthenticated caller rather than requiring a privileged account. This issue is fixed in version 1.3.0.Final.

  3. CVE-2026-111763 5.7 Moyenne

    a2aproject a2a-java

    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.

  4. CVE-2026-111762 5.7 Moyenne

    a2aproject a2a-java

    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.

  5. CVE-2026-111761 5.8 Moyenne

    a2aproject a2a-java

    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.