GHSA-68mj-5wr7-6fgg: Maven/com.rabbitmq:amqp-client vulnerability
Summary
ValueReader.readBytes() allocates a byte array sized by a wire-declared content length without validating it against actual frame data. A malicious AMQP peer triggers OOM by declaring a ~2GB string/bytes field.
Vulnerable Code
src/main/java/com/rabbitmq/client/impl/ValueReader.java lines 83-95:
java private static byte[] readBytes(final DataInputStream in) throws IOException { final long contentLength = unsignedExtend(in.readInt()); if(contentLength < Integer.MAXVALUE) { final byte[] buffer = new byte[(int)contentLength]; // allocates before reading in.readFully(buffer); return buffer; } }
Attack Scenario
A malicious AMQP server sends a LongString field (type tag 'S') with declared length 0x7FFFFFFE (2,147,483,646). The check contentLength < Integer.MAXVALUE passes. new byte[2147483646] attempts ~2GB allocation, causing OutOfMemoryError before readFully() attempts to read data.
The allocation size is attacker-controlled and is NOT validated against the frame size or TruncatedInputStream bounds. Exploitable pre-authentication via connection.start server-properties table.
Impact
Denial of service via JVM OutOfMemoryError. Crashes the entire JVM.
CWE
CWE-789: Memory Allocation with Excessive Size Value
Remediation
Validate contentLength against the frame's remaining bytes or the negotiated max frame size (default 131,072) before allocating.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
maven/com.rabbitmq:amqp-clientto a version that resolves this vulnerability.Fixed in 5.33.1 - Configuration
Implement the described fix: validate `contentLength` against the frame's remaining bytes or the negotiated max frame size (default 131,072) before allocating the byte array in `src/main/java/com/rabbitmq/client/impl/ValueReader.java` (lines 83-95).
AMQP client/JVM receiver (ValueReader.readBytes / com.rabbitmq.client.impl.ValueReader) contentLength validation = Reject/stop parsing when LongString declared length exceeds remaining bytes in the current frame or the negotiated max frame size (default 131072) before executing `new byte[(int)contentLength]`. - Compensating control
Add an external admission control to limit/inspect AMQP frame sizes and/or reject connections whose declared LongString/S field length is larger than the negotiated max frame size (default 131072) before traffic reaches the JVM.
Event History
Frequently Asked Questions
Who can realistically trigger this issue?
Clients are exposed when they connect to an untrusted or malicious AMQP peer. The vulnerable parsing path can be reached before authentication through the server-properties table in a connection.start response.
What does an attacker need to exploit it?
An attacker needs to operate, impersonate, or otherwise control the AMQP peer presented to the client and send a LongString or bytes field with a declared length near 2 GB. No valid payload of that size is required because the client allocates the declared size before attempting to read the field data.
What is the practical impact of a successful attack?
The immediate effect is a JVM OutOfMemoryError caused by an attempted allocation of approximately 2 GB. This can crash the affected client process and cause denial of service.