Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
12 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
com.rabbitmq.tools.json.JSONReader.read() never returns when its input ends inside a quoted string or a // line comment. Both scanners walk the input with StringCharacterIterator.next() but only compare against a delimiter, so once the iterator reaches CharacterIterator.DONE () they loop forever. The string scanner (string(), line 210, while (c != sep)) also appends to a StringBuilder every iteration, so it fills the heap and throws OutOfMemoryError, taking down the JVM. The comment scanner (skipWhiteSpace(), lines 89-92, while (c != '\n')) pins a thread at 100% CPU with no allocation. This is reachable with a single message. JsonRpcServer and JsonRpcClient fall back to DefaultJsonRpcMapper whenever no mapper is passed (JsonRpcServer.java:84 and :114, JsonRpcClient.java:186), and that mapper hands the raw message body straight to JSONReader.read() (DefaultJsonRpcMapper.java:42 for the server request, :52 for the client reply). A caller that can publish to the RPC request…
Recommended action: Upgrade to 5.36.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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.UTF8), which silently substitutes…
Recommended action: Upgrade to 5.36.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
When property-file/Map-based ConnectionFactory setup fails while parsing the uri key, the library wraps the underlying exception with the raw connection string — including the plaintext username and password — baked verbatim into the new exception's message. Details ConnectionFactoryConfigurator.load(ConnectionFactory, Map<String,String, String) (src/main/java/com/rabbitmq/client/ConnectionFactoryConfigurator.java, lines 142-155): String uri = properties.get(prefix + "uri"); if (uri != null) { try { cf.setUri(uri); } catch (URISyntaxException e) { throw new IllegalArgumentException("Error while setting AMQP URI: " + uri, e); } catch (NoSuchAlgorithmException e) { throw new IllegalArgumentException("Error while setting AMQP URI: " + uri, e); } catch (KeyManagementException e) { throw new IllegalArgumentException("Error while setting AMQP URI: " + uri, e); } } uri is the full AMQP URI — amqp(s)://username:password@host:port/vhost — concatenated verbatim into the exception…
Recommended action: Upgrade to 5.35.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vulnerability In AMQConnection.java (line 435-436), after Connection.Tune negotiation, the frame-max limit is set via: When frameMax = 0 (meaning "unlimited" per AMQP spec), Math.min(67108864, 0) = 0. This value is then passed to Utils.framePayloadLimit(0) which returns Integer.MAXVALUE (line 77-79 of Utils.java): This completely defeats the maxInboundMessageBodySize protection (default 64MB) at the frame level. Attack Scenario A malicious AMQP server (or MITM) sends Connection.Tune with frameMax=0: 1. Client defaults: requestedFrameMax = 0 (ConnectionFactory.DEFAULTFRAMEMAX, line 82) 2. negotiatedMaxValue(0, 0) = Math.max(0, 0) = 0 (line 673-676) 3. Math.min(maxInboundMessageBodySize, 0) = 0 — 64MB cap defeated 4. framePayloadLimit(0) = Integer.MAXVALUE — no frame size enforcement 5. Attacker sends a single frame with frameSize = 0x1FFFFFFF (~500MB) 6. Frame.readFrom() (line 135) executes new byte[frameSize] — OOM crash The frame does not need to be a body frame — method frames,…
Recommended action: Upgrade to 5.34.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The max body size was enforced to patch CVE-2023-46120, but even though that limit still works, the frame size itself still exceeds the given max size. Root cause The Java client records the AMQP 0-9-1 framemax negotiated during connection tuning, but the socket inbound frame reader continues to validate broker-controlled payload lengths against the much larger maxInboundMessageBodySize limit. A broker peer can therefore send a method frame whose payload is larger than the negotiated framemax, have it allocated and decoded, and complete the connection handshake instead of being rejected as a protocol violation. Reported by Team Atlanta.
Recommended action: Upgrade to 5.33.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Vulnerability Summary com.rabbitmq.client.TrustEverythingTrustManager accepts ANY TLS certificate (including null chains) and is used as the default trust manager when calling ConnectionFactory.useSslProtocol() without arguments. Combined with hostname verification being disabled by default, this enables trivial man-in-the-middle attacks. Affected Components - com.rabbitmq.client.TrustEverythingTrustManager — accepts any certificate - com.rabbitmq.client.ConnectionFactory.useSslProtocol() — uses TrustEverythingTrustManager - Hostname verification disabled by default (enableHostnameVerification() must be called explicitly) - com.rabbitmq.client.ConnectionFactory.getPassword() — returns plaintext with no redaction - Default port 5672 (plaintext) with PLAIN SASL — credentials sent unencrypted POC (Verified on Java 21, amqp-client 5.25.0) Attack Scenarios 1. MITM: Attacker presents self-signed cert → TrustEverythingTrustManager accepts it → all RabbitMQ traffic intercepted 2. Credential…
Recommended action: Upgrade to 5.33.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
RabbitMQ Java Client's inbound AMQP command assembly accepts a content header declaring a small body and then processes a larger body frame by throwing a raw UnsupportedOperationException from CommandAssembler. A broker peer that the client has connected to can use this malformed frame sequence to fail frame processing and tear down the client connection instead of receiving a clean protocol-level malformed-frame error. This was discovered based on an existing vulnerability CVE-2017-15699. Details Inbound frames enter the client through SocketFrameHandler.readFrame, which returns frames parsed from the peer-controlled input stream (src/main/java/com/rabbitmq/client/impl/SocketFrameHandler.java:197). AMQConnection.MainLoop reads each frame (src/main/java/com/rabbitmq/client/impl/AMQConnection.java:692) and dispatches non-zero-channel frames to the channel while the connection is open (src/main/java/com/rabbitmq/client/impl/AMQConnection.java:748 and…
Recommended action: Upgrade to 5.31.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The JSON-RPC tools in com.rabbitmq.tools.jsonrpc perform Class.forName(javaReturnType) with initialize=true on class names received from untrusted AMQP messages, without any validation or allowlist. Vulnerable code (ProcedureDescription.java:101-127): When a JsonRpcClient connects, it calls system.describe and receives a service description from the AMQP queue. The response JSON includes javaReturnType fields that are reflectively set via JSONUtil.tryFill(), triggering setJavaReturnType() → computeReturnTypeAsJavaClass() → Class.forName(javaReturnType). Attack scenario: 1. Victim uses JsonRpcClient to connect to a JSON-RPC service via RabbitMQ 2. Attacker (co-tenant on shared broker, or MITM) intercepts the system.describe request 3. Attacker responds with crafted javaReturnType values 4. Victim's client calls Class.forName(attackerInput) with default initialize=true 5. Static initializers of attacker-specified classes execute in victim's JVM Additionally, the loaded class from…
Recommended action: Upgrade to 5.33.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
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: 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…
Recommended action: Upgrade to 5.33.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
ValueReader.readTable() and readArray() recursively call readFieldValue() with no depth limit. A malicious AMQP peer can crash the client JVM by sending a deeply nested table structure. Vulnerable Code src/main/java/com/rabbitmq/client/impl/ValueReader.java lines 139-155 and 237-249: Attack Scenario A malicious AMQP server (or MitM) sends a connection.start frame with ~580 levels of nested tables. Each level costs ~7 bytes (4-byte length + 1-byte key length + 1-byte key + 1-byte type tag), totaling ~4060 bytes within the 131,072 byte max frame size. With the default JVM stack (~512KB, ~864 bytes/frame), this triggers StackOverflowError, killing the I/O thread. Exploitable pre-authentication since connection.start is the very first server frame. Impact Denial of service. StackOverflowError kills the client I/O thread. CWE CWE-674: Uncontrolled Recursion Remediation Add a depth counter to readTable/readArray/readFieldValue and throw MalformedFrameException when exceeding a…
Recommended action: Upgrade to 5.33.1 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
maxBodyLebgth was not used when receiving Message objects. Attackers could just send a very large Message causing a memory overflow and triggering an OOM Error. PoC RbbitMQ Use RabbitMQ 3.11.16 as MQ and specify Message Body size 512M (here it only needs to be larger than the Consumer memory) Start RabbitMQ Producer Build a String of length 256M and send it to Consumer Consumer First set the heap memory size to 128M Read the message sent by the Producer from the MQ and print the length Results Run the Producer first, then the Consumer Consumer throws OOM Exception Impact Users of RabbitMQ may suffer from DoS attacks from RabbitMQ Java client which will ultimately exhaust the memory of the consumer.
Recommended action: Upgrade to 5.18.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Pivotal Spring AMQP, 1.x versions prior to 1.7.10 and 2.x versions prior to 2.0.6, expose a man-in-the-middle vulnerability due to lack of hostname validation. A malicious user that has the ability to intercept traffic would be able to view data in transit.
Recommended action: Upgrade to 5.4.0 or 4.8.0 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.