Rabbitmq
Monthly
Denial of service in the RabbitMQ Java client (com.rabbitmq:amqp-client / rabbitmq-java-client) prior to the fixed release allows a single small, malformed JSON-RPC message body to permanently hang or crash a JVM. The deprecated com.rabbitmq.tools.jsonrpc tooling - JsonRpcServer and JsonRpcClient - falls back to DefaultJsonRpcMapper when no mapper is supplied, and that mapper hands raw message bodies straight to JSONReader.read(), whose string and comment scanners fail to stop at CharacterIterator.DONE. An input truncated inside a quoted string drives the parser into an unending append loop that exhausts the heap with OutOfMemoryError, while an unterminated // line comment pins a thread at 100% CPU indefinitely; neither condition is recoverable per request. Publicly available exploit code exists (a proof-of-concept is included in the vendor advisory) and the CVE is tracked by CISA SSVC with Exploitation=poc and Technical Impact=partial, though EPSS probability is low at roughly 0.49% (40th percentile) and no CISA KEV listing is present. The CVSS vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H indicates a network-reachable, unauthenticated availability-only impact.
Denial of service against RabbitMQ topic exchange routing can be triggered by an authenticated user who holds permissions to bind a queue to a topic exchange and to publish to that exchange: a binding key containing consecutive '#' multi-segment wildcards, combined with a publication that matches it, drives the topic matcher into combinatorially repeated trie walks and duplicate destination materialization, exhausting CPU and memory and disrupting routing for all tenants on the broker. All RabbitMQ server versions prior to 4.3.5 are affected, with impact assessed as availability-only (CVSS:3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H; vendor-published 7.1); there is no data disclosure or modification, and no public exploit identified at time of analysis. The issue is a conditional but genuine algorithmic-complexity DoS rather than a critical priority, because exploitation requires valid credentials with configure and write privileges on a topic exchange, and it is remediated by the vendor in 4.3.5.
Node-wide denial of service in RabbitMQ server 4.1.0 through 4.1.10, 4.2.0 through 4.2.8, and 4.3.0 through 4.3.2 occurs when the non-default rabbitmq_stream_management plugin is enabled: an authenticated management-UI user with access to the target vhost - but no configure, write, or read permission on the resulting streams - can issue a single PUT to /api/stream/super-streams/{vhost}/{name} whose binding-keys field is expanded into the full stream-name list before any resource permission check, forcing a large transient allocation. The advisory demonstrates one ~4.5 MB JSON PUT killing a RabbitMQ container capped at 768 MB, so effective denial of service is strongly dependent on a low memory ceiling; on hosts with ample memory the impact degrades to a temporary resource spike rather than a guaranteed crash. No exploitation in the wild has been confirmed and no public exploit code was identified at time of analysis, but the low privilege bar (any valid management credentials with vhost access) and high availability impact make it a realistic insider or compromised-credential risk for constrained deployments. The issue is fixed in RabbitMQ 4.3.3, 4.2.9, and 4.1.11.
OAuth2 client secret disclosure in the RabbitMQ Management UI affects versions 4.2.0 through 4.2.8 and 4.3.0 through 4.3.2, where the configured management.oauth_client_secret is embedded in the JavaScript served by the unauthenticated endpoint /js/oidc-oauth/bootstrap.js. Any party with network reachability to the management HTTP port can retrieve the secret with a simple GET request - authentication requirements confirmed unauthenticated (CVSS:3.1 AV:N/AC:L/PR:N/UI:N) and the assessed impact is high confidentiality loss (VC:H) with no integrity or availability impact. The flaw only manifests when OAuth2 authentication is enabled for the Management UI and the IdP flow uses a confidential client secret, so default or non-OAuth2 deployments are unaffected; no public exploit code has been identified at time of analysis, and the issue is fixed in 4.3.3 and 4.2.9.
Authentication denial of service in RabbitMQ affects deployments running the rabbitmq_auth_backend_oauth2 plugin from 3.13.0 through the fixed releases (4.3.3, 4.2.9, 4.1.14, 4.0.23, 3.13.18), where the JWKS signing-key fetch routine in uaajwt.erl fails to check the HTTP response status code and treats any well-formed HTTP transaction as a success, so a single non-200 response with valid JSON that lacks a 'keys' field wipes all cached signing keys and breaks OAuth2/JWT authentication for every user until the next successful refresh. The vulnerability is remotely reachable and unauthenticated (CVSS:4.0 PR:N / independent CVSS:3.1 PR:N), but exploitation depends on attack requirements being met (AT:P) - the attacker must induce or coincide with an error-returning JWKS response - and the resulting impact is a persistent availability outage (VC:N/VI:N/VA:H in the assessed vector, C:N/I:N/A:H in the independent 3.1 assessment), with no data exposure or code execution. No public exploit code was identified at time of analysis and there is no CISA KEV listing; treat this as a genuine availability threat rather than a top-tier emergency.
Stored cross-site scripting (XSS) in the RabbitMQ stream management UI allows an attacker who can present a trusted TLS client certificate with a crafted Distinguished Name to inject script into the certificate subject/issuer fields, which is then rendered unescaped when an operator opens the affected stream-connection detail page in the management UI. RabbitMQ 3.13.0 through 3.13.17, 4.0.x before 4.0.23, 4.1.x before 4.1.14, 4.2.x before 4.2.9, and 4.3.x before 4.3.3 are affected; fixes are released in 3.13.18, 4.0.23, 4.1.14, 4.2.9, and 4.3.3. There is no public exploit identified at time of analysis and the issue is not in CISA KEV, though the CVSS 4.0 base score is 7.6; the independent assessment rates real-world risk as low because exploitation requires non-default plugins, mutual-TLS with an attacker-controlled trusted certificate, and operator interaction (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:N).
Reflected cross-site scripting in the RabbitMQ management UI lets an attacker execute arbitrary JavaScript in the management interface origin by injecting content into a bearer token that is embedded unescaped in the OAuth bootstrap script generated by set_token_auth/2. RabbitMQ server 4.2.0 through 4.2.7 and 4.3.0/4.3.1 are affected only when the management plugin is configured with management.oauth_enabled=true, which is what exposes the OAuth bootstrap endpoint before authentication; the attacker must also induce an administrator to load the affected page (UI:R), and the cookie-based variant additionally requires the attacker to first plant an access_token cookie on the management host. The vendor-supplied CVSS 4.0 base score of 7.5 is higher than our independent CVSS 3.1 assessment (AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N), which better reflects the non-default configuration gate and the extra cookie-planting prerequisite; no public exploit code has been identified at time of analysis.
The RabbitMQ management plugin in versions 4.2.0 through 4.2.8 and 4.3.0 through 4.3.2 writes an 'auth' cookie containing the base64-encoded 'username:password' pair after a successful POST /login, with no HttpOnly, Secure, SameSite, or expiration attributes, so anyone who can read that cookie can trivially decode it back to plaintext administrator credentials. The flaw is not directly exploitable on its own: the attacker must also hold one of three separate primitives - a same-origin cross-site scripting foothold in the management UI, an HTTP-readable network position (cleartext or man-in-the-middle), or local read access to the victim's browser cookie store - which is why the vendor's 8.2 (CVSS 4.0, AT:P/AC:H) score overstates practical risk while the underlying confidentiality impact is high. No public exploit code or confirmed active exploitation was identified at time of analysis, and vendor fixes are available in RabbitMQ 4.2.8 and 4.3.2.
TLS client-authentication bypass in the RabbitMQ trust-store plugin lets a remote unauthenticated attacker whose forged self-signed certificate carries the issuer DN and serial number of any whitelisted certificate pass mutual-TLS authentication. Only deployments that have the rabbitmq_trust_store plugin enabled and wired in as the TLS verify_fun for a client-certificate listener are affected, and an attacker must first learn or guess at least one whitelisted certificate's {Issuer, Serial} pair, which is non-secret and is exposed by the plugin's list command, logs, or any copy of the certificate. All RabbitMQ server releases prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0 are vulnerable; vendor-released patches exist in those versions, and no public exploit identified at time of analysis.
Memory-exhaustion denial of service in RabbitMQ's Web-MQTT plugin (rabbitmq_web_mqtt) lets an unauthenticated remote attacker crash a broker node by sending a single WebSocket frame that is highly compressed and inflates to gigabytes in memory. Affected are RabbitMQ server releases prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6 and 4.3.0 whenever the Web-MQTT plugin is enabled and its listener (TCP 15675/15676) is network-reachable; the attacker only needs to negotiate RFC 7692 permessage-deflate during the upgrade and then send a zlib bomb, since decompression happens in the connection process before any MQTT CONNECT credentials are evaluated. No public exploit code was identified at time of analysis, exploitation requires the non-default plugin to be enabled, and the impact is availability-only (C:N/I:N/A:H) against the affected node. Vendor-released fixes are available in 3.13.15, 4.0.20, 4.1.11, 4.2.6 and 4.3.0.
Denial of service in RabbitMQ Server (versions prior to 4.3.0, 4.2.6, 4.1.11, 4.0.20, and 3.13.15) allows an authenticated AMQP 0-9-1 client with publish permission to exhaust broker memory by declaring an excessive content-header BodySize and streaming message fragments without completing assembly. The unvalidated uint64 BodySize bypasses the max_message_size check, which only runs at assembly completion, causing unbounded memory accumulation in the reader process until the memory alarm triggers or the node runs out of memory, degrading all publishers cluster-wide. No public exploit code has been identified at time of analysis, and vendor patches are available.
Denial of service in RabbitMQ versions prior to 4.2.7 and 4.3.1 allows any authenticated AMQP 0-9-1 client to crash the entire Erlang VM, taking down all vhosts and connections, by exhausting the atom table with roughly one million requests. The attack exploits the direct reply-to feature: queue names or routing keys beginning with 'amq.rabbitmq.reply-to.' cause an ETF-encoded pid node name to be passed to binary_to_atom without using binary_to_existing_atom, and because atoms are never garbage collected, the try/catch cannot reclaim them. Exploitation requires a valid AMQP connection (any credential, any permission level) and the ability to send the large number of operations; no public exploit identified at time of analysis.
Unauthenticated remote attackers can crash any RabbitMQ node with the AMQP 1.0 listener enabled by sending a single ~19-byte frame to TCP port 5672, causing the Erlang VM to exhaust heap memory and terminate, which takes down all tenants and protocols on that node. The flaw is an unbounded-allocation bug (CWE-770) in the AMQP 1.0 framing code that is reached before authentication completes, so no credentials or user interaction are required; only network reachability to the broker's AMQP 1.0 port is needed. Affected releases are RabbitMQ prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6, which contain the vendor-released fix; no public exploit code has been identified at time of analysis, and the issue is scored high severity (CVSS 8.2 v4.0 / assessed CVSS 3.1 7.5) with availability-only impact.
RabbitMQ brokers that use the OAuth2 plugin can silently fall back to disabled TLS certificate verification when no CA bundle can be located, allowing an attacker already positioned as a network man-in-the-middle to forge the JWKS response and inject arbitrary JWTs that the broker will accept as authentic. The flaw affects RabbitMQ server versions prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0, and exploitation requires four conditions to align: the OAuth2 plugin must be in use, no cacertfile may be configured, the host or container's OS CA bundle must be empty or unreadable, and the attacker must hold a MitM position on the path to the identity provider's JWKS endpoint. Unauthenticated remote attackers are the relevant threat actor per the CVSS vector (PR:N), but the precondition stack and the required network position make this a heavily gated authentication-bypass rather than a blanket internet-exploitable critical; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Stored cross-site scripting in the RabbitMQ management UI allows an attacker who can obtain a TLS client certificate signed by a CA the broker trusts to embed JavaScript in the certificate's Subject DN, which is rendered unescaped in the connection detail page and executes in an administrator's browser session when that connection is viewed. Success enables full administrative account takeover within the management UI - creating users, exporting definitions, and performing any action the viewing admin can perform. Exploitation is heavily gated: the TLS listener must be configured with ssl_options.verify = verify_peer (not the default), the certificate must be signed by a CA in the broker's trust store (self-signed certificates do not work), and an administrator must open the affected connection page; the management UI's CSP includes 'unsafe-inline', so inline script is not blocked. Patched versions are 3.13.15, 4.0.20, 4.1.11, and 4.2.6; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Memory exhaustion in the RabbitMQ Java client (all versions prior to 5.34.0) lets a rogue AMQP broker or an in-path attacker crash the JVM host application: when both the client's default ConnectionFactory.DEFAULT_FRAME_MAX and the server's Connection.Tune frame_max negotiate to 0, the library's maxInboundMessageBodySize cap is silently discarded and an oversized inbound frame is allocated without limit. Attackers cannot force this against a passive, correctly connected client - the victim must connect outbound to attacker-influenced infrastructure, or the attacker must hold a man-in-the-middle position able to rewrite the Connection.Tune frame and inject frames, which the vendor's CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VA:H) and our assessed CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) both treat as an unauthenticated, availability-only denial of service with no code execution or data exposure. Impact is limited to terminating the client process via heap exhaustion, and there is no public exploit identified at time of analysis and no CISA KEV listing; vendor-released patch: 5.34.0.
Denial of service in the RabbitMQ amqp091-go Go AMQP 0.9.1 client affects all releases prior to 1.13.0: the library's frame-dispatch path synchronously pushes publisher confirms, flow-control events, consumer cancellations, returned messages and connection-block notifications into application-registered listener channels, so an unbuffered, undersized or not-promptly-drained listener channel permanently blocks the connection's sole reader goroutine. Once that goroutine stalls, the client stops processing incoming frames, acknowledgments, deliveries and heartbeats, which leads to connection stalls, missed heartbeats, deadlocks and eventual broker-initiated disconnection; exploitation requires a broker-driven burst of the corresponding events against an application that registered an affected listener, rather than any attacker-supplied payload. Unauthenticated remote triggering is possible per the published PR:N vector, but only applications built on versions below 1.13.0 that back a notification listener with a small or undrained channel are exposed, and no public exploit code has been identified at time of analysis. The issue is fixed in v1.13.0, where each notification send is bounded by a 5-second timeout and slow deliveries are dropped instead of blocking the reader.
Parsing desynchronization in the RabbitMQ amqp091-go AMQP 0.9.1 client library before 1.13.0 lets a malicious or compromised broker - or anyone positioned to modify broker traffic - send a table field carrying a longstr whose declared length exceeds 0x7FFFFFFF; the client accepts it silently instead of returning ErrSyntax, leaves the declared bytes unread, and then parses every following field and frame from the wrong offset. The independent assessment rates this CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H, i.e. unauthenticated remote input that can corrupt parsing integrity and disrupt connection availability, but with high attack complexity because the victim application must first connect to an attacker-controlled or subverted broker (or be subject to a man-in-the-middle on that connection), and with no confidentiality impact since the Go library is memory-safe and this is a logic-level desynchronization rather than memory corruption. Vendor-released patch v1.13.0 fixes the defect; no public exploit code identified at time of analysis, and the vendor's CVSS 4.0 score of 9.5 with full High subsequent-system impact overstates real-world risk.
Denial of service in the official RabbitMQ Go client library amqp091-go (versions prior to 1.13.0): a malicious, compromised, or impersonated AMQP 0.9.1 broker can crash any application that connects to it. By encoding a byte-array field length as 0xFFFFFFFF (decoded into a signed int32 as -1) inside the connection.start server-properties table or a message header field table, the broker drives readField() to call make() with a negative size, producing a 'len out of range' runtime panic that escapes the reader goroutine and terminates the client process. Attackers must sit on the broker side of the connection - a trusted-broker deployment is largely unaffected - and the outcome is availability loss only, with no code execution or data disclosure. No public exploit code or confirmed active exploitation has been identified at time of analysis; vendor-released patch 1.13.0 is available.
RabbitMQ's amqp091-go Go client library, in all versions before 1.13.0, builds TLS configuration from amqps:// URIs without setting a minimum protocol version, so builds that use a Go runtime permitting TLS 1.0 or 1.1 can negotiate an obsolete protocol. An active man-in-the-middle positioned on the network path could then force a downgrade and weaken the confidentiality and integrity of AMQP traffic, including credentials, though the independently assessed vector (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N) shows this requires a high degree of attacker positioning plus the legacy-toolchain precondition, and the published 9.4 CVSS 4.0 score overstates real-world exposure for modern deployments. The fix is a two-line MinVersion change shipped in version 1.13.0; no public exploit identified at time of analysis.
Improper output encoding in the RabbitMQ amqp091-go Go client before 1.13.0 lets an attacker who can influence a TLS asset path value (CertFile, KeyFile, CACertFile, or ServerName) inject or overwrite AMQPS connection options whenever an application serializes a URI with URI.String() and later reparses it with ParseURI(). Because the values are concatenated into the query string without url.Values encoding, embedded '&' and '=' delimiters split into extra parameters that can redirect the client to different - but still pre-existing - local certificate, key, or CA files, corrupting connection configuration. There is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis; the vendor fix is version 1.13.0, and the practical risk is well below the headline 8.7 CVSS 4.0 score because exploitation needs a specific serialize-then-reparse code path plus attacker-influenceable path data.
Memory-exhaustion denial of service in the official RabbitMQ Go AMQP 0.9.1 client library (amqp091-go) prior to 1.13.0 lets a malicious or compromised broker kill client processes: when a content header frame arrives, the client preallocates the message body buffer using the broker-declared 64-bit body size without capping that hint to the negotiated Connection.Config.FrameSize, so an extreme declared size drives a correspondingly huge Go heap allocation before any body bytes are received, exhausting memory and terminating the process. The exploitation model is broker-attacks-its-clients rather than exploitation by an arbitrary network attacker (CVSS 4.0 8.9 with AT:P, and the assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H), meaning the victim application must connect to a broker that is hostile, subverted, or on a path an attacker can tamper with; no client credentials or unusual configuration are needed, and a FrameSize of 0 ("unlimited") removes the cap entirely even after patching. There is no CISA KEV entry and no public exploit identified at time of analysis, but the upstream fix commit, test case, and 1.13.0 release are all public.
Memory exhaustion in the RabbitMQ amqp091-go Go AMQP 0.9.1 client library prior to 1.13.0 lets unauthenticated remote attackers who can influence an application's Qos settings make the client request an absurdly large prefetch limit and then buffer enough broker-delivered messages to exhaust host memory. Channel.Qos performs no bounds validation, so a negative prefetchCount or prefetchSize is cast straight into the uint16/uint32 fields of the basic.qos method and wraps to 65535 or 4294967295 instead of being rejected. The vendor CVSS 4.0 score of 8.2 (High) is availability-only and materially gated by the attack requirement that the embedding application accept untrusted Qos values; default usage with hard-coded, non-negative values is unaffected, and no public exploit code was identified at time of analysis. The defect is repaired in 1.13.0 via a new validateQos check.
Denial of service in the RabbitMQ amqp091-go Go client for AMQP 0.9.1 (versions prior to 1.13.0) allows a malicious or compromised broker to advertise a FrameMax below the protocol's 4096-byte frameMinSize during connection negotiation, causing the client to fragment subsequent publications into an excessive number of frames and write operations, consuming CPU and stalling the client process or its host. The assessed vector carries PR:N, so no authentication is required on the client side, but exploitation is bounded by a trust-boundary prerequisite: the victim Go application must connect to a broker that the attacker controls or has compromised, and TLS with proper broker authentication prevents an unrelated network attacker from impersonating the broker. Impact is availability-only with no loss of confidentiality or integrity, and no public exploit code has been identified at time of analysis.
Credential disclosure in the RabbitMQ amqp091-go Go client library before 1.13.0 leaves PLAIN and AMQPLAIN SASL passwords sitting in the exported, plaintext Password fields of Connection.Config.SASL for the entire lifetime of an authenticated connection, because Connection.openComplete never clears them after the handshake. Any in-process code that walks the Connection object - reflective or structured loggers, APM agents, debugger utilities, or panic/crash handlers that serialize state - can pull those credentials into logs or dumps that an attacker with local access to the host, logs, or crash artifacts can then read. Exploitation is local and prerequisites-dependent (it requires connecting with PlainAuth/AMQPlainAuth and the presence of config-traversing tooling, plus read access to the resulting output); no public exploit code has been identified at time of analysis and the issue is fixed in v1.13.0.
Silent AMQP 0.9.1 metadata corruption in the RabbitMQ amqp091-go Go client library prior to 1.13.0 lets an application that assigns an oversized value to any shortstr message property (CorrelationId, ReplyTo, MessageId, Expiration, UserId, AppId, ContentType, ContentEncoding, or Type) serialize a wrapped uint8 length prefix alongside only a truncated value while reporting no error. The result is broken request/reply correlation, routing, tracing, and downstream message processing rather than code execution or disclosure; the flaw requires attacker-influenced data to reach a shortstr property, so applications that only set short, trusted, fixed-length values are not practically exposed. No public exploit code or confirmed active exploitation was identified at time of analysis, and version 1.13.0 contains the vendor fix (CVSS 4.0 base 9.1; our independent assessment scores this CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:L, reflecting no privileges required but a high attack-complexity precondition).
Unbounded memory allocation in amqp091-go (RabbitMQ's official Go AMQP 0.9.1 client) before v1.13.0 allows a malicious or compromised AMQP broker to force connected clients to allocate and process content body frames exceeding the negotiated frame_max limit, bypassing protocol framing constraints and causing application-layer denial of service. The root cause - confirmed via PR diff - is the client's blind acceptance of broker-advertised frame sizes during the TUNE handshake without enforcing the AMQP specification's minimum frame floor. No public exploit or CISA KEV listing exists at time of analysis; a vendor-released patch is available in v1.13.0.
Unvalidated Class.forName() with initialization enabled in RabbitMQ Java Client's JSON-RPC tooling allows a network-positioned attacker to trigger arbitrary static initializers in the victim JVM. Applications using com.rabbitmq:amqp-client before 5.33.0 that employ the JsonRpcClient class are exposed when an attacker can control or spoof the system.describe broker response - either as a co-tenant on a shared broker or via network interception. Successful exploitation achieves code-like effects through static initializer execution and a secondary type-confusion path via mapper.parse, with full confidentiality, integrity, and availability impact on the client process. No public exploit identified at time of analysis, and this CVE is not listed in CISA KEV.
Unbounded mutual recursion in the RabbitMQ Java client library (amqp-client <= 5.33.0) allows a malicious AMQP server or network intermediary to crash the client JVM before authentication completes. By sending approximately 580 levels of nested AMQP table structures within a single connection.start frame - well within the default 131,072-byte frame limit - an attacker triggers a StackOverflowError that kills the client's I/O processing thread, resulting in denial of service. No public exploit code has been published, but the GHSA advisory includes a precise technical breakdown and proof-of-concept payload specification, significantly lowering the bar for exploitation.
Memory exhaustion denial of service in the RabbitMQ Java client library (com.rabbitmq:amqp-client ≤ 5.33.0) allows a malicious AMQP peer to crash the client JVM by sending a LongString field with a wire-declared length near Integer.MAX_VALUE during the pre-authentication connection.start handshake. The ValueReader.readBytes() method allocates a byte array sized by the attacker-controlled wire value before validating it against actual frame data, causing a ~2 GB allocation and OutOfMemoryError that terminates the entire JVM process. No public exploit code has been identified at time of analysis, but the GHSA advisory discloses the exact vulnerable code path, the precise trigger value (0x7FFFFFFE), and the step-by-step attack scenario, making independent implementation trivial.
Authorization bypass in RabbitMQ topic permissions lets an authenticated user with restricted topic rights publish to or bind on topics they should be denied, but only during metadata-store failure windows. When the Khepri metadata store returns a lookup error, the topic-permission result collapses to 'undefined', which the internal authorization backend fails open and treats as 'allow'. There is no public exploit identified at time of analysis and it is not on CISA KEV; the CVSS 4.0 base score is 7.0.
Improper authorization in RabbitMQ broker (versions prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6) allows an authenticated client to create foreign bindings against another connection's volatile amq.rabbitmq.reply-to (direct reply-to) destination, so persistent route entries survive after unbind and can leak RPC reply traffic intended for other clients. The flaw stems from Khepri-backed deletion checks that omit these volatile pseudo-queues, letting stale routes persist. No public exploit identified at time of analysis; exploitation requires valid credentials and has high attack complexity per the vendor CVSS 4.0 vector.
Sensitive credential disclosure in RabbitMQ affects installations running the management plugin with OAuth 2 configured via management.oauth_client_secret, prior to versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6. The obsolete GET /api/auth endpoint returns the configured OAuth 2 client secret to unauthenticated callers, allowing any remote party with network reach to the management interface to harvest the credential and potentially impersonate the broker to its identity provider. No public exploit identified at time of analysis, and it is not listed in CISA KEV, though the fix and root cause are fully documented in the vendor GitHub Security Advisory GHSA-pj24-8j6m-vq9q.
Authentication bypass in RabbitMQ (broker versions prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6) lets a loopback-restricted account such as the default guest user authenticate from a remote network when the broker sits behind a trusted PROXY-protocol path and the backend listener is loopback-bound. Because the loopback check evaluates the listener-side socket address (which appears as 127.0.0.1 to the local proxy) instead of the real client source carried in the PROXY header, the 'local only' restriction on guest is silently defeated across AMQP 0-9-1, AMQP 1.0, and the Stream Protocol. SSVC records a proof-of-concept; there is no CISA KEV listing and EPSS is low (0.34%, 26th percentile), indicating the flaw is potent but not yet mass-exploited.
Memory-exhaustion denial of service in RabbitMQ server prior to 4.2.6 allows an unauthenticated remote client to crash or degrade the broker via its stream protocol listener. Because the stream listener fails to enforce the configured frame-size limit while assembling frames during authentication and before Tune negotiation, an attacker can declare oversized frame lengths and force unbounded memory allocation in rabbit_stream_core. No public exploit has been identified at time of analysis and it is not listed in CISA KEV; risk stems from the trivially reachable, pre-authentication attack surface (CVSS 7.5).
Stored cross-site scripting in the RabbitMQ management UI (versions prior to 4.2.5) lets a user holding queue/exchange declaration permissions inject JavaScript that executes in another user's browser when they view the Queues or Exchanges pages. The malicious payload is supplied via the x-internal-purpose queue or exchange argument, which is rendered into an HTML title attribute without escaping. There is no public exploit identified at time of analysis, and the issue is not listed in CISA KEV; it is fixed in RabbitMQ 4.2.5.
Server-side request forgery and NTLM credential exposure in the RabbitMQ management plugin (versions 4.1.0 to before 4.1.11 and 4.2.0 to before 4.2.6) on Windows lets remote actors coerce the broker into outbound DNS and SMB connections to attacker-controlled UNC paths. The static file handler rabbit_mgmt_wm_static passes URL-encoded backslashes to erl_prim_loader:read_file_info before path validation, but only when multiple management extension plugins are enabled. No public exploit has been identified at time of analysis, and the EPSS score is low (0.28%, 20th percentile) despite the CVSS 10.0 rating.
Uncontrolled resource consumption in the RabbitMQ Management plugin's HTTP API lets an authenticated client crash or degrade the broker by submitting oversized-but-valid JSON bodies. The flaw lives in read_complete_body, which validates accumulated body size before the final chunk but never checks the final combined size, so the with_decode and direct_request code paths buffer and decode payloads that exceed intended limits. Affected releases are all versions prior to 3.13.14, 4.0.19, 4.1.10, and 4.2.5; no public exploit identified at time of analysis and the issue is not listed in CISA KEV.
Denial of service in RabbitMQ 4.x allows an authenticated AMQP 1.0 publisher holding write permission on a target queue to store a crafted message body that misclassifies under the broker's optimized server_mode AMQP 1.0 parser, causing downstream AMQP 1.0 consumers to terminate while decoding the entry; cross-protocol conversion paths (AMQP 0-9-1 and similar) that perform full body decoding can likewise terminate the consumer protocol process. The broker itself remains alive, routing and authorization are not bypassed, and the defect is confined to consumer-side protocol processes, but acknowledgement-required delivery can redeliver the poisoned message and produce repeated failures. Vendor-released patches ship in RabbitMQ 4.0.24, 4.1.15, 4.2.10, and 4.3.4; no public exploit code was identified at time of analysis and CISA KEV does not list this CVE.
Authenticated denial of service in RabbitMQ 4.0.x, 4.1.x, 4.2.x and 4.3.x allows a low-privilege AMQP 1.0 client to inflate broker memory with tiny frames. Because the pre-authentication max_heap_size guard is removed after SASL login, a client can send ordinary frames containing many AMQP 1.0 arrays whose shared constructor is zero-width, each expanding into a large list of terms in the reader process heap before frame validation or authorization occurs; repeated or concurrent frames can trip the node-wide memory alarm and block publishers. No public exploit identified at time of analysis, and the issue is fixed in 4.0.24, 4.1.15, 4.2.10 and 4.3.4.
Denial of service in RabbitMQ's MQTT plugin lets an authenticated publisher using MQTT 5 force a single victim subscriber's connection to be dropped. Because the parser accepts the CONNECT-only Request-Problem-Information property on PUBLISH packets and the broker then routes it to matching subscribers, the outbound serialization path hits a missing clause in serialise_prop/2 and raises an uncontained function_clause that closes the victim's MQTT or Web MQTT connection. Exploitation requires valid broker credentials with topic-write permission on a topic that at least one other client subscribes to, and the broker, the publisher connection, and all other clients remain available; no public exploit code was identified at time of analysis, and no confirmed active exploitation (CISA KEV) has been reported.
Denial of service in the RabbitMQ amqp091-go AMQP 0.9.1 client library (1.13.0 through pre-1.14.0) lets a malicious or compromised AMQP peer force the client to allocate attacker-chosen amounts of memory during the handshake. The peer only needs to send a short body-frame header with a large declared payload length: because the pre-negotiation maxFrameSize value is stored as zero - a state indistinguishable from 'unlimited' - the earlier frame-size mitigation is bypassed and ReadFrame allocates based on the declared length before the payload arrives, before connection.tune completes, and before authentication, even when Config.FrameSize is set to the protocol minimum. Overall a MEDIUM real-world risk with unauthenticated remote triggering, but exploitation is limited to clients that connect via the public Open function to an attacker-controlled, compromised, or MITM'd broker, and the impact is confined to client availability (memory pressure, OOM termination, process loss) with no data exposure or code execution; no public exploit identified at time of analysis.
RabbitMQ Java Client library releases prior to 5.35.0 can leak plaintext broker credentials because ConnectionFactoryConfigurator.load() wraps AMQP URI parsing failures in IllegalArgumentException messages that contain the raw amqp://user:pass@host URI. Any application that supplies credentials inside the connection URI and then hits a setup error - malformed URI syntax or a TLS NoSuchAlgorithmException/KeyManagementException - will write those credentials into startup logs, APM dashboards, CI output, or copied stack traces, where users without broker access may read them. This is a genuine but low-urgency credential-disclosure issue rather than a widely-exploitable critical flaw: exploitation is passive and conditional, requires the attacker to already have read access to the log sink, and only affects the configurator load() path where credentials are embedded in the URI. No public exploit identified at time of analysis; the vulnerable behavior is fixed in version 5.35.0, and the CVSS 4.0 score of 5.7 (AV:L/AC:L/AT:P/PR:L, VC:H) reflects that local, low-privilege, log-reading access with specific preconditions is needed.
Malformed UTF-8 echoed back through an AMQP shortstr property can permanently disable RPC consumers built on the RabbitMQ Java client before 5.36.0, forcing the affected consumer to fail on every redelivery of a single poison message. An attacker with low-privileged broker access publishes a request whose property value (for example correlation-id) contains invalid UTF-8; ValueReader.readShortstr decodes those bytes into U+FFFD replacement characters, which re-encode to more than the 255-byte AMQP shortstr limit that ValueWriter.writeShortstr enforces, so reply publication throws an unchecked exception. In RpcServer.mainloop() and tutorial-style echo consumers that exception aborts the loop before acknowledgement, the broker requeues the message, and the consumer is stuck until the queue is purged. No public exploit identified at time of analysis; impact is confined to availability of the target consumer (reported CVSS 4.0 base 6.0; assessed CVSS 3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H) with no code execution, authentication bypass, or data exposure.
RabbitMQ OAuth credential refresh keeps revoked runtime tags on live AMQP connections in versions 3.13.0 up to the fixed 3.13.19, 4.0.24, 4.1.15, 4.2.10 and 4.3.5 releases, so an authenticated client (CVSS PR:L) that already held the privileged `impersonator` tag can keep publishing messages with a foreign AMQP userid after that privilege is withdrawn. The defect only affects connections that once held `impersonator` and then refresh in place to a same-username OAuth token that no longer grants it, with `rabbit_auth_backend_oauth2` (or an equivalent refresh-capable backend) enabled; a freshly opened connection using the downgraded token correctly refuses the same publish. No public exploit code has been identified at time of analysis, and the practical impact is a stale privilege-revocation gap for an already-privileged session rather than a route for an ordinary user to gain new privileges.
RabbitMQ Management versions 3.13.0 through 3.13.18, 4.0.23, 4.1.14, 4.2.9 and 4.3.4 render an attacker-controlled AMQP queue name as unescaped HTML in an authorization-error reason when the OAuth management UI is enabled, allowing an injected <base> element to retarget the UI's automatic relative refresh. An authenticated attacker holding queue 'configure' permission can therefore cause a management administrator who clicks 'Get Message(s)' on the crafted queue to send their Authorization header to an attacker-controlled endpoint whose CORS policy accepts the management origin. Exploitation requires a stacked set of preconditions - non-default OAuth UI, attacker queue-configure rights, an administrator who can see but cannot read the queue, a victim click, a Content Security Policy lacking base-uri and connect-src, and an attacker endpoint that permits the management origin via CORS - which substantially limits real-world risk; no public exploit identified at time of analysis, and the issue is rated MEDIUM (CVSS 4.0 base 4.5).
RabbitMQ Shovel plugin before 4.3.3, 4.2.9, 4.1.14, and 4.0.23 can write plaintext AMQP credentials from shovel worker GenServer state into crash dump files because the process does not implement the OTP format_status/2 callback; a crash (e.g., network partition) triggers the SASL error handler to serialize the full state, including deobfuscated amqp://user:password@host URIs. Exploitation is not remote: it requires the Shovel plugin to be configured with credentialed URIs, a subsequent crash, and authenticated high-privileged read access to the node's error log or crash dump (CVSS 3.1 PR:H), exposing credentials for the separate upstream/downstream brokers rather than the RabbitMQ node's own data. No public exploit has been identified at time of analysis, and vendor patches are available in the fixed versions.
Atom-table exhaustion in RabbitMQ 4.x lets an authenticated user who holds the 'policymaker' tag crash a broker node by sending a sustained stream of requests (roughly one million) to the Management plugin's /api/global-parameters/:name endpoint, each with a unique name value. The handler passes the URL segment through rabbit_data_coercion:to_atom/1, which uses the unsafe binary_to_atom/2; because Erlang atoms are never garbage collected, every novel name permanently consumes an atom-table slot until the VM aborts. Exposure requires the Management plugin to be enabled and an account above the management tag (but below administrator); it is not reachable unauthenticated, and the assessed impact is availability-only (no confidentiality or integrity loss). No public exploit code or confirmed active exploitation was identified at time of analysis, and the issue is fixed in RabbitMQ 4.0.22, 4.1.14, 4.2.7 and 4.3.1.
Authorization bypass in RabbitMQ's MQTT topic permission handling allows a low-privileged authenticated user to broaden read and write access to topics when an operator-defined permission template embeds the {clientid} variable inside a regex character class. The flaw is an incomplete fix for CVE-2026-44838, where the escaperegexchar/1 function fails to escape the hyphen, enabling a malicious clientid to alter the character class and bypass intended topic authorization. Affected versions include RabbitMQ 4.0.0 through 4.3.2, 4.0.x before 4.0.23, 4.1.x before 4.1.14, and 4.2.x before 4.2.9; the vendor rates this medium severity (CVSS 5.1), and no public exploit code has been identified at time of analysis.
Denial of service in RabbitMQ's management HTTP API lets an authenticated administrator crash the broker by submitting a user (or importing definitions) whose tags list contains roughly one million unique strings; each string is converted to a permanent Erlang atom until the bounded atom table is exhausted and the BEAM node dies. Affected versions are RabbitMQ 4.0.0 through 4.0.21, 4.1.x before 4.1.14, and 4.2.x before 4.2.7, and the attack requires the management plugin to be enabled and reachable plus full administrator privileges, so there is no unauthenticated or low-privilege path. No public exploit code identified at time of analysis, and vendor-released patches are available in 4.0.22, 4.1.14 and 4.2.7; this is a genuine but low-priority availability issue rather than a confidentiality or integrity risk.
Loopback source-address restriction bypass in RabbitMQ's native MQTT and MQTT-over-WebSocket listeners (all releases from 3.13.0 up to the fixed versions 3.13.18, 4.0.23, 4.1.14, 4.2.9 and 4.3.3) allows an authenticated attacker holding valid credentials for a loopback-restricted account to reach that account from a non-loopback address. The flaw only manifests when such a listener runs behind a trusted frontend that speaks PROXY Protocol: the proxy-derived client address is dropped before the MQTT authentication path evaluates the loopback_users setting, so the frontend-to-broker connection is mistakenly judged as loopback. Password authentication itself is not bypassed, CVSS 4.0 base is 6.0 with high attack complexity and a present attack requirement reflecting how deployment-specific the trigger is, no public exploit code has been identified at time of analysis, and the issue is not confirmed actively exploited (no CISA KEV listing).
Authenticated RabbitMQ tenants on affected releases can exhaust broker scheduler CPU and degrade or deny service to all co-tenants by creating a binding with a crafted rjms_erlang_selector LIKE expression on an x-jms-topic exchange. Only deployments running the optional rabbitmq_jms_topic_exchange plugin are exposed, and the attacker needs permissions both to create bindings on that exchange and to publish messages routing through them; no public exploit has been identified at time of analysis and the issue is not in CISA KEV. Impact is availability-only - confidentiality and integrity are unaffected - but a single malicious tenant can degrade a shared broker, so the issue warrants prompt patching rather than emergency escalation.
RabbitMQ 4.0.0 through 4.0.22, 4.1.x before 4.1.14, 4.2.x before 4.2.9, and 4.3.x before 4.3.3 exposes the complete binding topology of a virtual host to any authenticated AMQP 1.0 user, because the HTTP-over-AMQP management handler for GET /bindings (rabbit_amqp_management) returns the binding list without performing the resource-level read/write permission checks that every sibling operation in the same module performs. A low-privileged account with no management, monitoring, policymaker, or administrator tag - and no read/write permission on the relevant exchanges or queues - can enumerate source exchanges, destination queues and exchanges, routing keys, and binding arguments for any vhost it can connect to; only routing metadata is disclosed, not message payloads, and the classic HTTP management API GET /api/bindings is not affected because it validates permissions. Exploitation requires valid broker credentials (unauthenticated remote access is not sufficient), and no public exploit code or confirmed active exploitation was identified at time of analysis; the CVSS 4.0 base score of 6.3 primarily reflects the low-privilege network-reachable precondition with a high subsequent-system confidentiality contribution in the assessing vector, while an independent CVSS 3.1 assessment scores the flaw 6.1-class impact as limited to confidentiality only.
Denial of service in RabbitMQ 4.2.x (4.2.0 through before 4.2.9) and 4.3.x (before 4.3.3) lets an already highly privileged, authenticated user submit crafted Shovel runtime parameters through the Management HTTP API, causing the parser to intern attacker-controlled strings as Erlang atoms until the node-wide atom table is exhausted and the broker can no longer function. Exploitation demands network reach to the Management API plus credentials carrying both the management and policymaker tags, write permission on a vhost, and the non-default rabbitmq_shovel and rabbitmq_shovel_management plugins enabled; because the malicious parameters are persisted durably and re-parsed when workers start, the resource pressure can return after a restart without the attacker being connected. No public exploit code or evidence of active exploitation was identified at time of analysis, and the independent assessment rates this a genuine but low-priority DoS whose high-scoring optics are tempered by those heavy preconditions. Fixed in 4.2.9 and 4.3.3.
RabbitMQ's Federation plugin (3.13.0 up to the fixed 3.13.18, 4.0.24, 4.1.14, 4.2.9 and 4.3.3 releases) validates a federation upstream URI without performing any vhost-access authorization check, letting a principal that holds policymaker rights on one virtual host point an upstream at a different vhost and read and drain messages it has no permission on. With the default ack-mode the source messages are consumed (deleted) rather than copied, so the flaw combines unauthorized cross-vhost disclosure with destructive consumption. Exploitation is authenticated (CVSS PR:L) and contingent on a multi-tenant broker that actually runs Federation and grants untrusted principals policymaker rights, and no public exploit code or CISA KEV entry was identified at the time of analysis, making this a moderate authorization-boundary issue rather than a mass-exploitable emergency.
Expired OAuth2 JWT access tokens are accepted indefinitely by RabbitMQ 4.2.0 through 4.2.8 and 4.3.0 through 4.3.2 when the rabbitmq_auth_backend_oauth2 backend is enabled and the identity provider emits the JWT 'exp' claim as a fractional (float) JSON number rather than an integer. Because the Erlang code guards expiry parsing with is_integer(Exp), both the login-time expiry check and the mid-connection disconnect timer silently fall through for float exp values, so an attacker holding a previously issued, correctly signed token can authenticate with it long after it has expired and keep connections open without being disconnected. The CVSS 4.0 base score is 6.3, but exploitability is sharply conditional - a non-default IdP behavior plus possession of a valid signed token - and no public exploit code has been identified at time of analysis; the issue is fixed in RabbitMQ 4.2.9 and 4.3.3.
LDAP distinguished-name injection in the RabbitMQ rabbitmq_auth_backend_ldap plugin allows a remote, unauthenticated caller to manipulate the DN used for an LDAP bind by supplying a crafted username, because the ${username} placeholder is substituted into user_dn_pattern without RFC 4514 escaping. Impact is limited to integrity (CVSS:4.0 6.3 / CVSS:3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N) and exploitation is narrowly conditioned: the plugin must be enabled, user_dn_pattern must actually contain ${username}, the injected suffix must resolve to a useful directory entry, and the attacker must hold a password valid for that resulting DN. No public exploit code and no confirmed active exploitation were identified at time of analysis; upstream fix commits and patched releases exist, though the advisory's first-fixed version metadata is internally inconsistent for several maintenance lines.
Authenticated RabbitMQ Server 4.2.0 through 4.2.8 and 4.3.0 through 4.3.2 users who hold only 'configure' permission on one exchange can bypass the alternate-exchange authorization check through the AMQP 1.0 management API, silently redirecting unrouteable messages into a target exchange on which they have no write permission. The defect is a missing authorization check (CWE-862) in the PUT /exchanges/:name handler, reachable whenever AMQP 1.0 is enabled - the default in RabbitMQ 4.x - while the equivalent AMQP 0-9-1 channel path already enforces the check. Impact is confined to routing integrity with no confidentiality or availability loss; no public exploit code has been identified at time of analysis, and vendor-released patches are available in 4.2.9 and 4.3.3.
Denial of service via atom exhaustion in RabbitMQ Server when the rabbitmq_auth_backend_oauth2 plugin is enabled and configured with an identity provider that allows user-influenced scope values in signed JWTs. Affected versions include 3.13.0 through 3.13.14, 4.0.x before 4.0.22, 4.1.x before 4.1.11, 4.2.x before 4.2.6, and 4.3.x before 4.3.1. Exploitation requires valid signed tokens bearing novel 'tag:' scope values across many repeated logins, and no public exploit code has been identified at time of analysis; independent assessment rates real-world risk as low due to the non-default plugin, permissive IdP dependency, and high volume of authentications needed.
Administrator-tagged accounts on RabbitMQ can silently delete users that carry the 'protected' tag by calling the management plugin's POST /api/users/bulk-delete endpoint, which skips the protected-user guard that the single-user DELETE /api/users/:name path enforces. The flaw affects RabbitMQ 3.13.0 up to 3.13.14 and 4.0.x, 4.1.x, and 4.2.x releases before 4.0.20, 4.1.11, and 4.2.6, but only when the rabbitmq_management plugin is enabled and only for an attacker who already holds the highest management privilege ('administrator' tag), so the outcome is integrity loss (destruction of hardened service accounts) rather than any escalation of access. No public exploit identified at time of analysis, no confirmed active exploitation (CISA KEV), and no EPSS score was provided; the assessed CVSS:3.1 vector is AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N (CVSS 4.0 base 2.1), and realistic risk is confined to insider misuse, a compromised admin credential, or accidental bulk deletion.
Atom table exhaustion in RabbitMQ's management HTTP API lets an authenticated user who holds only the 'management' tag crash the broker's Erlang VM, taking down every vhost and tenant hosted on that node. The 'node' JSON field accepted by PUT /api/queues/:vhost/:name - and by the equivalent exchanges and bindings endpoints - is passed through rabbit_nodes:make/1 to list_to_atom/1 in rabbit_mgmt_util.erl:get_node/1 (lines ~880-885) with no cluster-membership check first, so each unique value permanently leaks one atom until the VM hits system_limit. About 900,000 unique requests are needed rather than a single call, which keeps this a moderate-severity, sustained-abuse availability issue; no public exploit code has been identified at time of analysis, and deployments are fixed by upgrading to 3.13.15, 4.0.20, 4.1.11 or 4.2.6.
Stale OAuth authentication-mechanism preferences can survive a logout in the RabbitMQ management UI on versions 4.2.0 through 4.2.7 and 4.3.0/4.3.1, because the plugin emits a non-ASCII cookie name when it tries to clear the strict_auth_mechanism or preferred_auth_mechanism cookie, and RFC 6265-compliant browsers refuse to delete a cookie whose name is not a valid token. The practical effect is limited to a persisted UI preference carrying across logout/login cycles; there is no code execution, data exfiltration, or confidentiality or availability impact, which is consistent with the NVD CVSS 4.0 base score of 2.3 and with the independent CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N assessment. Exploitation requires the management UI to be in active use and a logout/login cycle to occur, and no public exploit code or evidence of active exploitation was identified at time of analysis.
A remote, unauthenticated denial-of-service condition exists in the RabbitMQ stream protocol when the stream plugin is enabled, allowing a client that completes the Tune handshake to declare a frame larger than the negotiated FrameMax and drive excessive memory consumption. Affected deployments are RabbitMQ 3.13.0 through 3.13.14, 4.0.x before 4.0.20, 4.1.x before 4.1.11, and 4.2.x before 4.2.6; the issue is availability-only with no confidentiality or integrity impact, and exploitation requires the non-default stream plugin (and its listener) to be exposed to the attacker. No public exploit code has been identified at time of analysis, and there is no confirmed active exploitation (CISA KEV) associated with this CVE. Independent assessment rates this as a genuine but low-to-moderate-severity DoS issue rather than a high-impact priority.
Unbounded pre-authentication state accumulation in RabbitMQ's Web STOMP WebSocket handler lets an unauthenticated remote client hold connections open with a slow trickle of small frames, causing memory and resource exhaustion on the broker. Only deployments that enable the non-default rabbitmq_web_stomp plugin and expose its WebSocket listener are affected; a single request is not enough, since the attacker must open and sustain many slow connections over time (reflected as AT:P in the assessed vector). RabbitMQ 3.13.0 through 3.13.14, 4.0.x before 4.0.20, 4.1.x before 4.1.11, and 4.2.x before 4.2.6 are vulnerable, and no public exploit code has been identified at time of analysis.
Authenticated denial of service in RabbitMQ brokers running 3.13.0 through the fixed releases 3.13.15, 4.0.20, 4.1.11 and 4.2.6 lets a management user holding the policymaker tag exhaust the Erlang VM atom table and crash the node by submitting an auth_mechanism value containing a very large number of colon-delimited tokens. Exploitation is sharply gated: the Shovel or Federation plugin must be enabled on the target node, and only the privileged policymaker tag can set the auth_mechanism field, so the actor must already be a trusted high-privilege operator rather than an anonymous remote client. Impact is availability-only (node crash), with no data disclosure or modification; no public exploit code has been identified at time of analysis, and vendor-released patches (3.13.15, 4.0.20, 4.1.11, 4.2.6) are available.
RabbitMQ's shovel management resource fails to enforce a policymaker-level check on DELETE operations, so an authenticated user holding the low-privileged 'monitoring' tag - nominally read-only - can delete or restart any dynamic shovel in any vhost visible to that account. The flaw (CWE-862 missing authorization) is reachable over the network with no user interaction and yields high integrity impact against shovel configuration state, though it is bounded by a non-default configuration requiring both the rabbitmq_shovel and rabbitmq_shovel_management plugins to be enabled and by the attacker needing pre-existing credentials plus vhost-scoped visibility. Patches are released in RabbitMQ 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.1; no public exploit code has been identified and there is no confirmed active exploitation (no CISA KEV listing) at time of analysis.
RabbitMQ's Shovel plugin leaks broker credentials on deployments that configure AMQP 1.0 shovels with the username and password embedded directly in the connection URI: in versions prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0 the plugin persists the raw URI instead of sanitizing it the way the AMQP 0-9-1 shovel does via amqp_uri:remove_credentials. Any authenticated user holding the 'monitoring' management tag can read those plaintext credentials from GET /api/shovels or rabbitmqctl shovel_status, and can then reuse them against the remote AMQP 1.0 endpoint. There is no public exploit code identified at time of analysis and no confirmed active exploitation (no CISA KEV listing); the exposure is a passive, read-only credential disclosure whose practical severity is narrowed by the non-default URI-embedded-credential configuration and the monitoring-tag requirement. This is a genuine but modest-priority information-disclosure issue rather than a high-urgency flaw.
RabbitMQ stream-management HTTP API allows an authenticated user holding the management tag and vhost access - but no configure permission on any resource - to create super-streams, which consist of an exchange, N partition stream queues, and their bindings, without the per-resource authorization check the native stream protocol path enforces. This is a genuine but low-impact authorization flaw (CWE-862 missing authorization) rated CVSS 2.1 by the vendor and an assessed CVSS:3.1 of AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N, since the impact is confined to unauthorized integrity changes (persistent resource creation) with no data disclosure or denial of service. Exploitation requires the non-default rabbitmq_stream_management plugin to be enabled and a management-tagged account with vhost access; no KEV listing or public exploit was identified, and vendor fixes are available in 4.0.22, 4.1.11, 4.2.6, and 4.3.0.
Denial of service in RabbitMQ (all server releases prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6 and 4.3.0) allows an authenticated user holding the management tag to burn broker CPU through the supported use_regex=true option on management list endpoints. The caller-supplied ?name= pattern is passed to Erlang/OTP's re:run without a match_limit and executed once per resource in the result set, so on a broker with roughly 5000 queues a single request can consume 12 or more minutes of scheduler time, and parallel requests can saturate the schedulers and degrade availability for all clients. There is no confidentiality or integrity impact, no public exploit code identified at time of analysis, and the risk is bounded by the management-tag requirement, no user interaction being needed but a resource-rich deployment being necessary for the effect to be felt.
Cross-Site WebSocket Hijacking (CWE-1385) in RabbitMQ's Web-MQTT and Web-STOMP plugins allows attacker-controlled JavaScript running in a victim's browser to open an authenticated WebSocket connection to the broker, because the WebSocket upgrade handlers at rabbit_web_mqtt_handler.erl:104 and rabbit_web_stomp_handler.erl:102 never validate the Origin header. The flaw is only reachable under non-default configuration - Web-STOMP with use_http_auth=true, or either plugin with ssl_cert_login=true - where the browser automatically presents the victim's TLS client certificate, letting the attacker inherit the victim's identity; the issue is harmless under the default in-band CONNECT credential setup, so default deployments are unaffected. No public exploit has been identified at time of analysis, but the CVSS:3.1 assessment (AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:N) rates the confidentiality and integrity impact as high where a vulnerable configuration is in use.
Broken access control in the RabbitMQ management HTTP API lets a user holding only the monitoring tag restart any federation link via DELETE /api/federation-links/.../restart, an operation that should require elevated (management/policymaker/administrator) privileges - thereby disrupting message flow between federated brokers. Affected are RabbitMQ server releases prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.1, but only deployments that enable both the rabbitmq_federation and rabbitmq_federation_management plugins and have at least one active federation link. Exploitation requires an authenticated account carrying the monitoring tag (CVSS v4.0 PR:L), impact is limited to availability of the restarted link, the assessed severity is CVSS 2.3 / CVSS:3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L, and no public exploit code or confirmed in-the-wild exploitation was identified at time of analysis.
Memory exhaustion in the RabbitMQ consistent-hash exchange plugin lets an authenticated user with ordinary binding permissions drive broker-wide memory allocation from a single binding. Prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6 and 4.3.0, validate_binding/2 accepts an unbounded integer weight N from the binding routing key and expands it with lists:seq/2; a weight of 100000000 allocates roughly 800 MB on every node, and because the resulting list is written into the exchange's Khepri record it is replicated cluster-wide and reloaded on restart, so a restart does not clear the condition. Exploitation requires the rabbitmq_consistent_hash_exchange plugin to be enabled (it is not enabled by default) plus a low-privilege account holding write on a consistent-hash exchange and read on a queue; no public exploit identified at time of analysis.
Denial of service in RabbitMQ prior to versions 4.2.7 and 4.3.1 allows a remote, authenticated user holding the 'policymaker' tag to crash a broker node by exhausting the Erlang atom table. The runtime-parameters API lookup path coerces the attacker-controlled :component URL segment into a brand-new atom on every request, and because the atom table is bounded and atoms are never garbage collected, roughly one million requests with distinct component values are enough to fill it and bring the node down. Impact is availability-only (no data exposure or modification), exploitation requires high privileges and a very large request volume, and no public exploit code has been identified at time of analysis - the independent assessment rates this a moderate, low-urgency issue and the vendor has released fixed versions 4.2.7 and 4.3.1.
RabbitMQ brokers running the Shovel plugin can write decrypted shovel URIs - including credentials embedded directly in the URI (amqp://user:password@host/) - into the broker log file when DEBUG-level logging is enabled and a shovel configured with src-delete-after=N (autodelete) completes and is torn down. The exposure is confined to log files: anyone who already holds read access to the broker log or a downstream log aggregation pipeline can recover working AMQP credentials, which they can then use to authenticate to the message broker. Exploitation is not remote or unauthenticated (the vendor-adjacent assessment rates it CVSS:3.1 AV:L/AC:L/PR:H/UI:N with high confidentiality impact only), and it requires a chain of non-default conditions: the Shovel plugin enabled, credentials embedded in shovel URIs, DEBUG logging explicitly turned on, and an autodelete shovel. No public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (no CISA KEV listing); no EPSS score was supplied with the source data.
Denial of service in RabbitMQ affects every server release prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0, where importing a crafted definitions file can exhaust the Erlang atom table and crash the node. The issue is reachable only by an authenticated user holding the RabbitMQ administrator tag: a definitions import containing a vhosts entry with roughly one million unique metadata keys slips under the 20 MB management body limit and is passed by add_vhost/2 into the unsafe rabbit_data_coercion:atomize_keys/1 path (binary_to_atom) with no whitelist or cap, killing the node that processes the request. Impact is limited to availability loss on a single node (no disclosure or tampering), exploitation is gated behind administrator privileges, and no public exploit code was identified at time of analysis; vendor-released fixes are available in the versions listed above.
Memory exhaustion in RabbitMQ Server (versions prior to 4.1.11, 4.2.6, and 4.3.0) lets a caller holding the management tag crash or severely degrade a broker by submitting a stream partition request whose count is unbounded - validate_partitions only enforces a lower bound of 1, so a value such as lists:seq(0, 500000000) drives roughly 8GB of allocation. Exploitation requires three conditions to hold simultaneously: the rabbitmq_stream_management plugin must be enabled (it is off by default), the caller must carry the management tag, and the caller must have access to the target vhost; with those met, impact is availability-only (CVSS 5.9, PR:H, no confidentiality or integrity effect) and can cross tenant boundaries on a shared broker. No public exploit code has been identified at time of analysis and there is no confirmed active exploitation, keeping this a genuine but bounded availability risk rather than an emergency.
Authenticated CPU exhaustion in RabbitMQ Server prior to 4.2.7 and 4.3.1 lets an AMQP 1.0 consumer that holds both read and write permission on a stream queue drive substantial backtracking work in the broker's regex engine: a crafted LIKE filter built from roughly two thousand overlapping '%_' wildcard pairs, combined with long message property values, forces about 100-200 ms of CPU to be consumed per delivered message. The impact is bounded resource amplification rather than a node crash or hang, consistent with a low-severity denial-of-service rating (CVSS 4.0 base 2.3; independent assessment CVSS 3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L), and no public exploit code has been identified at time of analysis. Exposure is limited to deployments that actually use AMQP 1.0 with stream queues and SQL filter expressions; systems not using that combination are unaffected.
Cross-tenant information disclosure in RabbitMQ's management HTTP API lets any authenticated user holding the 'management' tag read Raft quorum-queue status - leader, members, term, commit index - for queues in vhosts they cannot access, because the /api/queues/quorum/:vhost/:queue/status handler authorizes only the management tag rather than the target vhost. Affected are RabbitMQ deployments running the management plugin at versions prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0, with impact confined to read-only exposure of queue names and cluster topology in multi-tenant setups. No public exploit identified at time of analysis; EPSS and KEV signals are absent, and the assessed CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) rates this low severity.
An authenticated denial-of-service condition in RabbitMQ Server allows a stream-protocol user with read access to any stream to crash the broker node by exhausting the Erlang atom table. The flaw affects RabbitMQ Server releases prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.1, but only when the rabbitmq_stream plugin is enabled - deployments without that plugin are not exposed. Exploitation requires valid stream credentials (CVSS 4.0 vector shows PR:L, and the assessed vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) and the repeated submission of many frames carrying distinct chunk_selector values, which is why the severity is scored as a moderate-priority availability issue rather than a critical remote-code flaw. No public exploit code or confirmed active exploitation has been identified at time of analysis.
Authenticated tenants can bypass operator-configured per-user and per-vhost connection limits in RabbitMQ by connecting to the stream protocol listener on port 5552 instead of the AMQP listener on port 5672, allowing resource-exhaustion conditions that the operator believed were prevented. The flaw affects RabbitMQ Server releases prior to 4.2.7 and 4.3.1 when the rabbitmq_stream plugin is enabled, and the code path was fixed in those two maintenance releases. Exploitation requires valid stream-protocol credentials and an environment where per-user or per-vhost connection caps are actually relied upon as a tenant-isolation control; no public exploit code was identified at time of analysis and there is no confirmed active exploitation (CISA KEV).
Authenticated RabbitMQ users that hold the 'monitoring' tag can erase a node's authentication-attempt counters by sending DELETE /api/auth/attempts/:node through the Management plugin HTTP API, removing a signal that operators would use to notice brute-force activity. Only deployments running RabbitMQ prior to 4.1.13, 4.2.7 or 4.3.0 with the Management plugin enabled and monitoring credentials issued to a non-administrative or untrusted account are exposed, and exploitation requires the attacker to already possess that valid account. The impact is limited to in-memory metrics (no log or audit-record deletion) and no public exploit code has been identified at time of analysis; EPSS data was not supplied and the issue is not in CISA KEV, consistent with its very low assessed severity.
Atom-table exhaustion in RabbitMQ's x-jms-topic exchange lets an authenticated low-privilege AMQP user crash an entire broker node in fewer than 100 binding declarations, turning a vhost-confined account into a cross-tenant denial of service. The flaw is reachable only when the bundled rabbitmq_jms_topic_exchange plugin is enabled - standard in any JMS deployment - and the attacker holds read permission on an x-jms-topic exchange plus write permission on a queue, or configure rights to declare both; it also requires a raw AMQP client, because the broker does not enforce the client-side selector compilation that the Java JMS client performs. Fixed in RabbitMQ 3.13.15, 4.0.20, 4.1.11, 4.2.6 and 4.3.0; no public exploit identified at time of analysis and no CISA KEV listing, though the attack needs no user interaction and is network-reachable, with an assessed CVSS 3.1 score of AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H.
Path traversal in the RabbitMQ tracing plugin lets a user holding the administrator tag write a file to an arbitrary filesystem location writable by the rabbitmq OS user, because the trace consumer builds its output path as filename:join(TraceDir, Name ++ ".log") from the unvalidated Name parameter of PUT /api/traces/:vhost/:name. Exploitation is an authenticated, administrator-only operation (CVSS vector PR:H) and requires that the rabbitmq_tracing plugin is explicitly enabled and that the target directory is already writable by the broker's OS account, so the realistic scenario is insider or post-compromise abuse rather than an externally reachable flaw. Impact is limited to integrity of local files (I:L, C:N/A:N) and is further constrained by the mandatory .log suffix, which restricts writes to .log-suffixed targets and makes any escalation to code execution opportunistic; no public exploit identified at time of analysis, and the issue is rated 2.1 (CVSS 4.0), consistent with a low-priority, high-privilege finding. Fixed versions are 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.1.
TLS certificate validation is completely bypassed in the RabbitMQ Java client library (`com.rabbitmq:amqp-client`) prior to version 5.33.0 when applications call `ConnectionFactory.useSslProtocol()` or `useSslProtocol(String)`, because these methods silently install `TrustEverythingTrustManager` and leave hostname verification disabled. A network-positioned attacker can present any certificate - including self-signed or null-chain - to impersonate the RabbitMQ broker and decrypt or modify all AMQP traffic, including plaintext credentials transmitted via PLAIN SASL on default port 5672. A verified proof-of-concept is publicly available in GHSA-5m9f-rphj-c435; no confirmed active exploitation (CISA KEV) has been recorded at time of analysis.
Denial of service in the RabbitMQ Java client library (com.rabbitmq:amqp-client ≤ 5.30.0) allows a malicious or compromised AMQP broker to forcibly terminate any active client connection by sending a crafted malformed frame sequence. The flaw in CommandAssembler.consumeBodyFrame subtracts a peer-controlled body-frame payload length before validating it fits within the declared body size, driving remainingBodyBytes negative and triggering an unhandled UnsupportedOperationException - a legacy stub - rather than a proper MalformedFrameException, causing AMQConnection to perform a hard connection shutdown. A PoC is referenced in the GHSA advisory; no active exploitation is confirmed in CISA KEV.
Authenticated RabbitMQ users can bypass authorization controls on passive AMQP 0-9-1 declare operations, exposing internal broker topology metadata across all affected release branches (3.13.x, 4.0.x, 4.1.x, 4.2.x). The missing authorization check on passive queue.declare and exchange.declare allows any user with vhost connectivity to enumerate queue and exchange names and read live message and consumer counts without requiring elevated permissions. No public exploit code has been identified and the vulnerability is not in CISA KEV; however, the low exploitation complexity, authentication-only prerequisite, and broad affected version range meaningfully elevate real-world exposure risk in multi-tenant or shared-credential deployments.
RabbitMQ Server prior to 4.2.6 fails to cancel or reauthorize existing AMQP 0-9-1 consumers when an OAuth token expires or when connection.update_secret reduces token scopes, allowing an authenticated consumer to continue receiving messages it is no longer authorized to access. The broker evaluates authorization only at consumer registration time, not at message delivery time, creating a persistent authorization bypass window for as long as the connection remains open. No public exploit exists at time of analysis, but the CVSS 4.0 vector assigns high subsequent-system confidentiality impact (SC:H), reflecting meaningful data-access risk in OAuth-governed or multi-tenant deployments.
Stored cross-site scripting in the RabbitMQ federation management plugin allows any user with federation upstream or policy configuration privileges to execute arbitrary JavaScript in the browser of an administrator viewing the Federation Status page. The rabbitmq_federation_management plugin renders the consumer_tag field without HTML escaping, making it a persistent injection vector that fires passively when a victim navigates to the page. No public exploit code and no CISA KEV listing are identified at time of analysis; the CVSS 4.0 score of 5.7 reflects meaningful but constrained risk due to the high-privilege prerequisite.
RabbitMQ is a multi-protocol messaging broker. Rated medium severity (CVSS 4.8), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
RabbitMQ is a multi-protocol messaging broker. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
Denial of service in the RabbitMQ Java client (com.rabbitmq:amqp-client / rabbitmq-java-client) prior to the fixed release allows a single small, malformed JSON-RPC message body to permanently hang or crash a JVM. The deprecated com.rabbitmq.tools.jsonrpc tooling - JsonRpcServer and JsonRpcClient - falls back to DefaultJsonRpcMapper when no mapper is supplied, and that mapper hands raw message bodies straight to JSONReader.read(), whose string and comment scanners fail to stop at CharacterIterator.DONE. An input truncated inside a quoted string drives the parser into an unending append loop that exhausts the heap with OutOfMemoryError, while an unterminated // line comment pins a thread at 100% CPU indefinitely; neither condition is recoverable per request. Publicly available exploit code exists (a proof-of-concept is included in the vendor advisory) and the CVE is tracked by CISA SSVC with Exploitation=poc and Technical Impact=partial, though EPSS probability is low at roughly 0.49% (40th percentile) and no CISA KEV listing is present. The CVSS vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H indicates a network-reachable, unauthenticated availability-only impact.
Denial of service against RabbitMQ topic exchange routing can be triggered by an authenticated user who holds permissions to bind a queue to a topic exchange and to publish to that exchange: a binding key containing consecutive '#' multi-segment wildcards, combined with a publication that matches it, drives the topic matcher into combinatorially repeated trie walks and duplicate destination materialization, exhausting CPU and memory and disrupting routing for all tenants on the broker. All RabbitMQ server versions prior to 4.3.5 are affected, with impact assessed as availability-only (CVSS:3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H; vendor-published 7.1); there is no data disclosure or modification, and no public exploit identified at time of analysis. The issue is a conditional but genuine algorithmic-complexity DoS rather than a critical priority, because exploitation requires valid credentials with configure and write privileges on a topic exchange, and it is remediated by the vendor in 4.3.5.
Node-wide denial of service in RabbitMQ server 4.1.0 through 4.1.10, 4.2.0 through 4.2.8, and 4.3.0 through 4.3.2 occurs when the non-default rabbitmq_stream_management plugin is enabled: an authenticated management-UI user with access to the target vhost - but no configure, write, or read permission on the resulting streams - can issue a single PUT to /api/stream/super-streams/{vhost}/{name} whose binding-keys field is expanded into the full stream-name list before any resource permission check, forcing a large transient allocation. The advisory demonstrates one ~4.5 MB JSON PUT killing a RabbitMQ container capped at 768 MB, so effective denial of service is strongly dependent on a low memory ceiling; on hosts with ample memory the impact degrades to a temporary resource spike rather than a guaranteed crash. No exploitation in the wild has been confirmed and no public exploit code was identified at time of analysis, but the low privilege bar (any valid management credentials with vhost access) and high availability impact make it a realistic insider or compromised-credential risk for constrained deployments. The issue is fixed in RabbitMQ 4.3.3, 4.2.9, and 4.1.11.
OAuth2 client secret disclosure in the RabbitMQ Management UI affects versions 4.2.0 through 4.2.8 and 4.3.0 through 4.3.2, where the configured management.oauth_client_secret is embedded in the JavaScript served by the unauthenticated endpoint /js/oidc-oauth/bootstrap.js. Any party with network reachability to the management HTTP port can retrieve the secret with a simple GET request - authentication requirements confirmed unauthenticated (CVSS:3.1 AV:N/AC:L/PR:N/UI:N) and the assessed impact is high confidentiality loss (VC:H) with no integrity or availability impact. The flaw only manifests when OAuth2 authentication is enabled for the Management UI and the IdP flow uses a confidential client secret, so default or non-OAuth2 deployments are unaffected; no public exploit code has been identified at time of analysis, and the issue is fixed in 4.3.3 and 4.2.9.
Authentication denial of service in RabbitMQ affects deployments running the rabbitmq_auth_backend_oauth2 plugin from 3.13.0 through the fixed releases (4.3.3, 4.2.9, 4.1.14, 4.0.23, 3.13.18), where the JWKS signing-key fetch routine in uaajwt.erl fails to check the HTTP response status code and treats any well-formed HTTP transaction as a success, so a single non-200 response with valid JSON that lacks a 'keys' field wipes all cached signing keys and breaks OAuth2/JWT authentication for every user until the next successful refresh. The vulnerability is remotely reachable and unauthenticated (CVSS:4.0 PR:N / independent CVSS:3.1 PR:N), but exploitation depends on attack requirements being met (AT:P) - the attacker must induce or coincide with an error-returning JWKS response - and the resulting impact is a persistent availability outage (VC:N/VI:N/VA:H in the assessed vector, C:N/I:N/A:H in the independent 3.1 assessment), with no data exposure or code execution. No public exploit code was identified at time of analysis and there is no CISA KEV listing; treat this as a genuine availability threat rather than a top-tier emergency.
Stored cross-site scripting (XSS) in the RabbitMQ stream management UI allows an attacker who can present a trusted TLS client certificate with a crafted Distinguished Name to inject script into the certificate subject/issuer fields, which is then rendered unescaped when an operator opens the affected stream-connection detail page in the management UI. RabbitMQ 3.13.0 through 3.13.17, 4.0.x before 4.0.23, 4.1.x before 4.1.14, 4.2.x before 4.2.9, and 4.3.x before 4.3.3 are affected; fixes are released in 3.13.18, 4.0.23, 4.1.14, 4.2.9, and 4.3.3. There is no public exploit identified at time of analysis and the issue is not in CISA KEV, though the CVSS 4.0 base score is 7.6; the independent assessment rates real-world risk as low because exploitation requires non-default plugins, mutual-TLS with an attacker-controlled trusted certificate, and operator interaction (CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:N).
Reflected cross-site scripting in the RabbitMQ management UI lets an attacker execute arbitrary JavaScript in the management interface origin by injecting content into a bearer token that is embedded unescaped in the OAuth bootstrap script generated by set_token_auth/2. RabbitMQ server 4.2.0 through 4.2.7 and 4.3.0/4.3.1 are affected only when the management plugin is configured with management.oauth_enabled=true, which is what exposes the OAuth bootstrap endpoint before authentication; the attacker must also induce an administrator to load the affected page (UI:R), and the cookie-based variant additionally requires the attacker to first plant an access_token cookie on the management host. The vendor-supplied CVSS 4.0 base score of 7.5 is higher than our independent CVSS 3.1 assessment (AV:N/AC:H/PR:N/UI:R/S:C/C:L/I:L/A:N), which better reflects the non-default configuration gate and the extra cookie-planting prerequisite; no public exploit code has been identified at time of analysis.
The RabbitMQ management plugin in versions 4.2.0 through 4.2.8 and 4.3.0 through 4.3.2 writes an 'auth' cookie containing the base64-encoded 'username:password' pair after a successful POST /login, with no HttpOnly, Secure, SameSite, or expiration attributes, so anyone who can read that cookie can trivially decode it back to plaintext administrator credentials. The flaw is not directly exploitable on its own: the attacker must also hold one of three separate primitives - a same-origin cross-site scripting foothold in the management UI, an HTTP-readable network position (cleartext or man-in-the-middle), or local read access to the victim's browser cookie store - which is why the vendor's 8.2 (CVSS 4.0, AT:P/AC:H) score overstates practical risk while the underlying confidentiality impact is high. No public exploit code or confirmed active exploitation was identified at time of analysis, and vendor fixes are available in RabbitMQ 4.2.8 and 4.3.2.
TLS client-authentication bypass in the RabbitMQ trust-store plugin lets a remote unauthenticated attacker whose forged self-signed certificate carries the issuer DN and serial number of any whitelisted certificate pass mutual-TLS authentication. Only deployments that have the rabbitmq_trust_store plugin enabled and wired in as the TLS verify_fun for a client-certificate listener are affected, and an attacker must first learn or guess at least one whitelisted certificate's {Issuer, Serial} pair, which is non-secret and is exposed by the plugin's list command, logs, or any copy of the certificate. All RabbitMQ server releases prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0 are vulnerable; vendor-released patches exist in those versions, and no public exploit identified at time of analysis.
Memory-exhaustion denial of service in RabbitMQ's Web-MQTT plugin (rabbitmq_web_mqtt) lets an unauthenticated remote attacker crash a broker node by sending a single WebSocket frame that is highly compressed and inflates to gigabytes in memory. Affected are RabbitMQ server releases prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6 and 4.3.0 whenever the Web-MQTT plugin is enabled and its listener (TCP 15675/15676) is network-reachable; the attacker only needs to negotiate RFC 7692 permessage-deflate during the upgrade and then send a zlib bomb, since decompression happens in the connection process before any MQTT CONNECT credentials are evaluated. No public exploit code was identified at time of analysis, exploitation requires the non-default plugin to be enabled, and the impact is availability-only (C:N/I:N/A:H) against the affected node. Vendor-released fixes are available in 3.13.15, 4.0.20, 4.1.11, 4.2.6 and 4.3.0.
Denial of service in RabbitMQ Server (versions prior to 4.3.0, 4.2.6, 4.1.11, 4.0.20, and 3.13.15) allows an authenticated AMQP 0-9-1 client with publish permission to exhaust broker memory by declaring an excessive content-header BodySize and streaming message fragments without completing assembly. The unvalidated uint64 BodySize bypasses the max_message_size check, which only runs at assembly completion, causing unbounded memory accumulation in the reader process until the memory alarm triggers or the node runs out of memory, degrading all publishers cluster-wide. No public exploit code has been identified at time of analysis, and vendor patches are available.
Denial of service in RabbitMQ versions prior to 4.2.7 and 4.3.1 allows any authenticated AMQP 0-9-1 client to crash the entire Erlang VM, taking down all vhosts and connections, by exhausting the atom table with roughly one million requests. The attack exploits the direct reply-to feature: queue names or routing keys beginning with 'amq.rabbitmq.reply-to.' cause an ETF-encoded pid node name to be passed to binary_to_atom without using binary_to_existing_atom, and because atoms are never garbage collected, the try/catch cannot reclaim them. Exploitation requires a valid AMQP connection (any credential, any permission level) and the ability to send the large number of operations; no public exploit identified at time of analysis.
Unauthenticated remote attackers can crash any RabbitMQ node with the AMQP 1.0 listener enabled by sending a single ~19-byte frame to TCP port 5672, causing the Erlang VM to exhaust heap memory and terminate, which takes down all tenants and protocols on that node. The flaw is an unbounded-allocation bug (CWE-770) in the AMQP 1.0 framing code that is reached before authentication completes, so no credentials or user interaction are required; only network reachability to the broker's AMQP 1.0 port is needed. Affected releases are RabbitMQ prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6, which contain the vendor-released fix; no public exploit code has been identified at time of analysis, and the issue is scored high severity (CVSS 8.2 v4.0 / assessed CVSS 3.1 7.5) with availability-only impact.
RabbitMQ brokers that use the OAuth2 plugin can silently fall back to disabled TLS certificate verification when no CA bundle can be located, allowing an attacker already positioned as a network man-in-the-middle to forge the JWKS response and inject arbitrary JWTs that the broker will accept as authentic. The flaw affects RabbitMQ server versions prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0, and exploitation requires four conditions to align: the OAuth2 plugin must be in use, no cacertfile may be configured, the host or container's OS CA bundle must be empty or unreadable, and the attacker must hold a MitM position on the path to the identity provider's JWKS endpoint. Unauthenticated remote attackers are the relevant threat actor per the CVSS vector (PR:N), but the precondition stack and the required network position make this a heavily gated authentication-bypass rather than a blanket internet-exploitable critical; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Stored cross-site scripting in the RabbitMQ management UI allows an attacker who can obtain a TLS client certificate signed by a CA the broker trusts to embed JavaScript in the certificate's Subject DN, which is rendered unescaped in the connection detail page and executes in an administrator's browser session when that connection is viewed. Success enables full administrative account takeover within the management UI - creating users, exporting definitions, and performing any action the viewing admin can perform. Exploitation is heavily gated: the TLS listener must be configured with ssl_options.verify = verify_peer (not the default), the certificate must be signed by a CA in the broker's trust store (self-signed certificates do not work), and an administrator must open the affected connection page; the management UI's CSP includes 'unsafe-inline', so inline script is not blocked. Patched versions are 3.13.15, 4.0.20, 4.1.11, and 4.2.6; no public exploit code and no confirmed active exploitation were identified at time of analysis.
Memory exhaustion in the RabbitMQ Java client (all versions prior to 5.34.0) lets a rogue AMQP broker or an in-path attacker crash the JVM host application: when both the client's default ConnectionFactory.DEFAULT_FRAME_MAX and the server's Connection.Tune frame_max negotiate to 0, the library's maxInboundMessageBodySize cap is silently discarded and an oversized inbound frame is allocated without limit. Attackers cannot force this against a passive, correctly connected client - the victim must connect outbound to attacker-influenced infrastructure, or the attacker must hold a man-in-the-middle position able to rewrite the Connection.Tune frame and inject frames, which the vendor's CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N/VA:H) and our assessed CVSS 3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) both treat as an unauthenticated, availability-only denial of service with no code execution or data exposure. Impact is limited to terminating the client process via heap exhaustion, and there is no public exploit identified at time of analysis and no CISA KEV listing; vendor-released patch: 5.34.0.
Denial of service in the RabbitMQ amqp091-go Go AMQP 0.9.1 client affects all releases prior to 1.13.0: the library's frame-dispatch path synchronously pushes publisher confirms, flow-control events, consumer cancellations, returned messages and connection-block notifications into application-registered listener channels, so an unbuffered, undersized or not-promptly-drained listener channel permanently blocks the connection's sole reader goroutine. Once that goroutine stalls, the client stops processing incoming frames, acknowledgments, deliveries and heartbeats, which leads to connection stalls, missed heartbeats, deadlocks and eventual broker-initiated disconnection; exploitation requires a broker-driven burst of the corresponding events against an application that registered an affected listener, rather than any attacker-supplied payload. Unauthenticated remote triggering is possible per the published PR:N vector, but only applications built on versions below 1.13.0 that back a notification listener with a small or undrained channel are exposed, and no public exploit code has been identified at time of analysis. The issue is fixed in v1.13.0, where each notification send is bounded by a 5-second timeout and slow deliveries are dropped instead of blocking the reader.
Parsing desynchronization in the RabbitMQ amqp091-go AMQP 0.9.1 client library before 1.13.0 lets a malicious or compromised broker - or anyone positioned to modify broker traffic - send a table field carrying a longstr whose declared length exceeds 0x7FFFFFFF; the client accepts it silently instead of returning ErrSyntax, leaves the declared bytes unread, and then parses every following field and frame from the wrong offset. The independent assessment rates this CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:H, i.e. unauthenticated remote input that can corrupt parsing integrity and disrupt connection availability, but with high attack complexity because the victim application must first connect to an attacker-controlled or subverted broker (or be subject to a man-in-the-middle on that connection), and with no confidentiality impact since the Go library is memory-safe and this is a logic-level desynchronization rather than memory corruption. Vendor-released patch v1.13.0 fixes the defect; no public exploit code identified at time of analysis, and the vendor's CVSS 4.0 score of 9.5 with full High subsequent-system impact overstates real-world risk.
Denial of service in the official RabbitMQ Go client library amqp091-go (versions prior to 1.13.0): a malicious, compromised, or impersonated AMQP 0.9.1 broker can crash any application that connects to it. By encoding a byte-array field length as 0xFFFFFFFF (decoded into a signed int32 as -1) inside the connection.start server-properties table or a message header field table, the broker drives readField() to call make() with a negative size, producing a 'len out of range' runtime panic that escapes the reader goroutine and terminates the client process. Attackers must sit on the broker side of the connection - a trusted-broker deployment is largely unaffected - and the outcome is availability loss only, with no code execution or data disclosure. No public exploit code or confirmed active exploitation has been identified at time of analysis; vendor-released patch 1.13.0 is available.
RabbitMQ's amqp091-go Go client library, in all versions before 1.13.0, builds TLS configuration from amqps:// URIs without setting a minimum protocol version, so builds that use a Go runtime permitting TLS 1.0 or 1.1 can negotiate an obsolete protocol. An active man-in-the-middle positioned on the network path could then force a downgrade and weaken the confidentiality and integrity of AMQP traffic, including credentials, though the independently assessed vector (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:L/A:N) shows this requires a high degree of attacker positioning plus the legacy-toolchain precondition, and the published 9.4 CVSS 4.0 score overstates real-world exposure for modern deployments. The fix is a two-line MinVersion change shipped in version 1.13.0; no public exploit identified at time of analysis.
Improper output encoding in the RabbitMQ amqp091-go Go client before 1.13.0 lets an attacker who can influence a TLS asset path value (CertFile, KeyFile, CACertFile, or ServerName) inject or overwrite AMQPS connection options whenever an application serializes a URI with URI.String() and later reparses it with ParseURI(). Because the values are concatenated into the query string without url.Values encoding, embedded '&' and '=' delimiters split into extra parameters that can redirect the client to different - but still pre-existing - local certificate, key, or CA files, corrupting connection configuration. There is no confirmed active exploitation (not in CISA KEV) and no public exploit code identified at time of analysis; the vendor fix is version 1.13.0, and the practical risk is well below the headline 8.7 CVSS 4.0 score because exploitation needs a specific serialize-then-reparse code path plus attacker-influenceable path data.
Memory-exhaustion denial of service in the official RabbitMQ Go AMQP 0.9.1 client library (amqp091-go) prior to 1.13.0 lets a malicious or compromised broker kill client processes: when a content header frame arrives, the client preallocates the message body buffer using the broker-declared 64-bit body size without capping that hint to the negotiated Connection.Config.FrameSize, so an extreme declared size drives a correspondingly huge Go heap allocation before any body bytes are received, exhausting memory and terminating the process. The exploitation model is broker-attacks-its-clients rather than exploitation by an arbitrary network attacker (CVSS 4.0 8.9 with AT:P, and the assessed CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H), meaning the victim application must connect to a broker that is hostile, subverted, or on a path an attacker can tamper with; no client credentials or unusual configuration are needed, and a FrameSize of 0 ("unlimited") removes the cap entirely even after patching. There is no CISA KEV entry and no public exploit identified at time of analysis, but the upstream fix commit, test case, and 1.13.0 release are all public.
Memory exhaustion in the RabbitMQ amqp091-go Go AMQP 0.9.1 client library prior to 1.13.0 lets unauthenticated remote attackers who can influence an application's Qos settings make the client request an absurdly large prefetch limit and then buffer enough broker-delivered messages to exhaust host memory. Channel.Qos performs no bounds validation, so a negative prefetchCount or prefetchSize is cast straight into the uint16/uint32 fields of the basic.qos method and wraps to 65535 or 4294967295 instead of being rejected. The vendor CVSS 4.0 score of 8.2 (High) is availability-only and materially gated by the attack requirement that the embedding application accept untrusted Qos values; default usage with hard-coded, non-negative values is unaffected, and no public exploit code was identified at time of analysis. The defect is repaired in 1.13.0 via a new validateQos check.
Denial of service in the RabbitMQ amqp091-go Go client for AMQP 0.9.1 (versions prior to 1.13.0) allows a malicious or compromised broker to advertise a FrameMax below the protocol's 4096-byte frameMinSize during connection negotiation, causing the client to fragment subsequent publications into an excessive number of frames and write operations, consuming CPU and stalling the client process or its host. The assessed vector carries PR:N, so no authentication is required on the client side, but exploitation is bounded by a trust-boundary prerequisite: the victim Go application must connect to a broker that the attacker controls or has compromised, and TLS with proper broker authentication prevents an unrelated network attacker from impersonating the broker. Impact is availability-only with no loss of confidentiality or integrity, and no public exploit code has been identified at time of analysis.
Credential disclosure in the RabbitMQ amqp091-go Go client library before 1.13.0 leaves PLAIN and AMQPLAIN SASL passwords sitting in the exported, plaintext Password fields of Connection.Config.SASL for the entire lifetime of an authenticated connection, because Connection.openComplete never clears them after the handshake. Any in-process code that walks the Connection object - reflective or structured loggers, APM agents, debugger utilities, or panic/crash handlers that serialize state - can pull those credentials into logs or dumps that an attacker with local access to the host, logs, or crash artifacts can then read. Exploitation is local and prerequisites-dependent (it requires connecting with PlainAuth/AMQPlainAuth and the presence of config-traversing tooling, plus read access to the resulting output); no public exploit code has been identified at time of analysis and the issue is fixed in v1.13.0.
Silent AMQP 0.9.1 metadata corruption in the RabbitMQ amqp091-go Go client library prior to 1.13.0 lets an application that assigns an oversized value to any shortstr message property (CorrelationId, ReplyTo, MessageId, Expiration, UserId, AppId, ContentType, ContentEncoding, or Type) serialize a wrapped uint8 length prefix alongside only a truncated value while reporting no error. The result is broken request/reply correlation, routing, tracing, and downstream message processing rather than code execution or disclosure; the flaw requires attacker-influenced data to reach a shortstr property, so applications that only set short, trusted, fixed-length values are not practically exposed. No public exploit code or confirmed active exploitation was identified at time of analysis, and version 1.13.0 contains the vendor fix (CVSS 4.0 base 9.1; our independent assessment scores this CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:L, reflecting no privileges required but a high attack-complexity precondition).
Unbounded memory allocation in amqp091-go (RabbitMQ's official Go AMQP 0.9.1 client) before v1.13.0 allows a malicious or compromised AMQP broker to force connected clients to allocate and process content body frames exceeding the negotiated frame_max limit, bypassing protocol framing constraints and causing application-layer denial of service. The root cause - confirmed via PR diff - is the client's blind acceptance of broker-advertised frame sizes during the TUNE handshake without enforcing the AMQP specification's minimum frame floor. No public exploit or CISA KEV listing exists at time of analysis; a vendor-released patch is available in v1.13.0.
Unvalidated Class.forName() with initialization enabled in RabbitMQ Java Client's JSON-RPC tooling allows a network-positioned attacker to trigger arbitrary static initializers in the victim JVM. Applications using com.rabbitmq:amqp-client before 5.33.0 that employ the JsonRpcClient class are exposed when an attacker can control or spoof the system.describe broker response - either as a co-tenant on a shared broker or via network interception. Successful exploitation achieves code-like effects through static initializer execution and a secondary type-confusion path via mapper.parse, with full confidentiality, integrity, and availability impact on the client process. No public exploit identified at time of analysis, and this CVE is not listed in CISA KEV.
Unbounded mutual recursion in the RabbitMQ Java client library (amqp-client <= 5.33.0) allows a malicious AMQP server or network intermediary to crash the client JVM before authentication completes. By sending approximately 580 levels of nested AMQP table structures within a single connection.start frame - well within the default 131,072-byte frame limit - an attacker triggers a StackOverflowError that kills the client's I/O processing thread, resulting in denial of service. No public exploit code has been published, but the GHSA advisory includes a precise technical breakdown and proof-of-concept payload specification, significantly lowering the bar for exploitation.
Memory exhaustion denial of service in the RabbitMQ Java client library (com.rabbitmq:amqp-client ≤ 5.33.0) allows a malicious AMQP peer to crash the client JVM by sending a LongString field with a wire-declared length near Integer.MAX_VALUE during the pre-authentication connection.start handshake. The ValueReader.readBytes() method allocates a byte array sized by the attacker-controlled wire value before validating it against actual frame data, causing a ~2 GB allocation and OutOfMemoryError that terminates the entire JVM process. No public exploit code has been identified at time of analysis, but the GHSA advisory discloses the exact vulnerable code path, the precise trigger value (0x7FFFFFFE), and the step-by-step attack scenario, making independent implementation trivial.
Authorization bypass in RabbitMQ topic permissions lets an authenticated user with restricted topic rights publish to or bind on topics they should be denied, but only during metadata-store failure windows. When the Khepri metadata store returns a lookup error, the topic-permission result collapses to 'undefined', which the internal authorization backend fails open and treats as 'allow'. There is no public exploit identified at time of analysis and it is not on CISA KEV; the CVSS 4.0 base score is 7.0.
Improper authorization in RabbitMQ broker (versions prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6) allows an authenticated client to create foreign bindings against another connection's volatile amq.rabbitmq.reply-to (direct reply-to) destination, so persistent route entries survive after unbind and can leak RPC reply traffic intended for other clients. The flaw stems from Khepri-backed deletion checks that omit these volatile pseudo-queues, letting stale routes persist. No public exploit identified at time of analysis; exploitation requires valid credentials and has high attack complexity per the vendor CVSS 4.0 vector.
Sensitive credential disclosure in RabbitMQ affects installations running the management plugin with OAuth 2 configured via management.oauth_client_secret, prior to versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6. The obsolete GET /api/auth endpoint returns the configured OAuth 2 client secret to unauthenticated callers, allowing any remote party with network reach to the management interface to harvest the credential and potentially impersonate the broker to its identity provider. No public exploit identified at time of analysis, and it is not listed in CISA KEV, though the fix and root cause are fully documented in the vendor GitHub Security Advisory GHSA-pj24-8j6m-vq9q.
Authentication bypass in RabbitMQ (broker versions prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6) lets a loopback-restricted account such as the default guest user authenticate from a remote network when the broker sits behind a trusted PROXY-protocol path and the backend listener is loopback-bound. Because the loopback check evaluates the listener-side socket address (which appears as 127.0.0.1 to the local proxy) instead of the real client source carried in the PROXY header, the 'local only' restriction on guest is silently defeated across AMQP 0-9-1, AMQP 1.0, and the Stream Protocol. SSVC records a proof-of-concept; there is no CISA KEV listing and EPSS is low (0.34%, 26th percentile), indicating the flaw is potent but not yet mass-exploited.
Memory-exhaustion denial of service in RabbitMQ server prior to 4.2.6 allows an unauthenticated remote client to crash or degrade the broker via its stream protocol listener. Because the stream listener fails to enforce the configured frame-size limit while assembling frames during authentication and before Tune negotiation, an attacker can declare oversized frame lengths and force unbounded memory allocation in rabbit_stream_core. No public exploit has been identified at time of analysis and it is not listed in CISA KEV; risk stems from the trivially reachable, pre-authentication attack surface (CVSS 7.5).
Stored cross-site scripting in the RabbitMQ management UI (versions prior to 4.2.5) lets a user holding queue/exchange declaration permissions inject JavaScript that executes in another user's browser when they view the Queues or Exchanges pages. The malicious payload is supplied via the x-internal-purpose queue or exchange argument, which is rendered into an HTML title attribute without escaping. There is no public exploit identified at time of analysis, and the issue is not listed in CISA KEV; it is fixed in RabbitMQ 4.2.5.
Server-side request forgery and NTLM credential exposure in the RabbitMQ management plugin (versions 4.1.0 to before 4.1.11 and 4.2.0 to before 4.2.6) on Windows lets remote actors coerce the broker into outbound DNS and SMB connections to attacker-controlled UNC paths. The static file handler rabbit_mgmt_wm_static passes URL-encoded backslashes to erl_prim_loader:read_file_info before path validation, but only when multiple management extension plugins are enabled. No public exploit has been identified at time of analysis, and the EPSS score is low (0.28%, 20th percentile) despite the CVSS 10.0 rating.
Uncontrolled resource consumption in the RabbitMQ Management plugin's HTTP API lets an authenticated client crash or degrade the broker by submitting oversized-but-valid JSON bodies. The flaw lives in read_complete_body, which validates accumulated body size before the final chunk but never checks the final combined size, so the with_decode and direct_request code paths buffer and decode payloads that exceed intended limits. Affected releases are all versions prior to 3.13.14, 4.0.19, 4.1.10, and 4.2.5; no public exploit identified at time of analysis and the issue is not listed in CISA KEV.
Denial of service in RabbitMQ 4.x allows an authenticated AMQP 1.0 publisher holding write permission on a target queue to store a crafted message body that misclassifies under the broker's optimized server_mode AMQP 1.0 parser, causing downstream AMQP 1.0 consumers to terminate while decoding the entry; cross-protocol conversion paths (AMQP 0-9-1 and similar) that perform full body decoding can likewise terminate the consumer protocol process. The broker itself remains alive, routing and authorization are not bypassed, and the defect is confined to consumer-side protocol processes, but acknowledgement-required delivery can redeliver the poisoned message and produce repeated failures. Vendor-released patches ship in RabbitMQ 4.0.24, 4.1.15, 4.2.10, and 4.3.4; no public exploit code was identified at time of analysis and CISA KEV does not list this CVE.
Authenticated denial of service in RabbitMQ 4.0.x, 4.1.x, 4.2.x and 4.3.x allows a low-privilege AMQP 1.0 client to inflate broker memory with tiny frames. Because the pre-authentication max_heap_size guard is removed after SASL login, a client can send ordinary frames containing many AMQP 1.0 arrays whose shared constructor is zero-width, each expanding into a large list of terms in the reader process heap before frame validation or authorization occurs; repeated or concurrent frames can trip the node-wide memory alarm and block publishers. No public exploit identified at time of analysis, and the issue is fixed in 4.0.24, 4.1.15, 4.2.10 and 4.3.4.
Denial of service in RabbitMQ's MQTT plugin lets an authenticated publisher using MQTT 5 force a single victim subscriber's connection to be dropped. Because the parser accepts the CONNECT-only Request-Problem-Information property on PUBLISH packets and the broker then routes it to matching subscribers, the outbound serialization path hits a missing clause in serialise_prop/2 and raises an uncontained function_clause that closes the victim's MQTT or Web MQTT connection. Exploitation requires valid broker credentials with topic-write permission on a topic that at least one other client subscribes to, and the broker, the publisher connection, and all other clients remain available; no public exploit code was identified at time of analysis, and no confirmed active exploitation (CISA KEV) has been reported.
Denial of service in the RabbitMQ amqp091-go AMQP 0.9.1 client library (1.13.0 through pre-1.14.0) lets a malicious or compromised AMQP peer force the client to allocate attacker-chosen amounts of memory during the handshake. The peer only needs to send a short body-frame header with a large declared payload length: because the pre-negotiation maxFrameSize value is stored as zero - a state indistinguishable from 'unlimited' - the earlier frame-size mitigation is bypassed and ReadFrame allocates based on the declared length before the payload arrives, before connection.tune completes, and before authentication, even when Config.FrameSize is set to the protocol minimum. Overall a MEDIUM real-world risk with unauthenticated remote triggering, but exploitation is limited to clients that connect via the public Open function to an attacker-controlled, compromised, or MITM'd broker, and the impact is confined to client availability (memory pressure, OOM termination, process loss) with no data exposure or code execution; no public exploit identified at time of analysis.
RabbitMQ Java Client library releases prior to 5.35.0 can leak plaintext broker credentials because ConnectionFactoryConfigurator.load() wraps AMQP URI parsing failures in IllegalArgumentException messages that contain the raw amqp://user:pass@host URI. Any application that supplies credentials inside the connection URI and then hits a setup error - malformed URI syntax or a TLS NoSuchAlgorithmException/KeyManagementException - will write those credentials into startup logs, APM dashboards, CI output, or copied stack traces, where users without broker access may read them. This is a genuine but low-urgency credential-disclosure issue rather than a widely-exploitable critical flaw: exploitation is passive and conditional, requires the attacker to already have read access to the log sink, and only affects the configurator load() path where credentials are embedded in the URI. No public exploit identified at time of analysis; the vulnerable behavior is fixed in version 5.35.0, and the CVSS 4.0 score of 5.7 (AV:L/AC:L/AT:P/PR:L, VC:H) reflects that local, low-privilege, log-reading access with specific preconditions is needed.
Malformed UTF-8 echoed back through an AMQP shortstr property can permanently disable RPC consumers built on the RabbitMQ Java client before 5.36.0, forcing the affected consumer to fail on every redelivery of a single poison message. An attacker with low-privileged broker access publishes a request whose property value (for example correlation-id) contains invalid UTF-8; ValueReader.readShortstr decodes those bytes into U+FFFD replacement characters, which re-encode to more than the 255-byte AMQP shortstr limit that ValueWriter.writeShortstr enforces, so reply publication throws an unchecked exception. In RpcServer.mainloop() and tutorial-style echo consumers that exception aborts the loop before acknowledgement, the broker requeues the message, and the consumer is stuck until the queue is purged. No public exploit identified at time of analysis; impact is confined to availability of the target consumer (reported CVSS 4.0 base 6.0; assessed CVSS 3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:H) with no code execution, authentication bypass, or data exposure.
RabbitMQ OAuth credential refresh keeps revoked runtime tags on live AMQP connections in versions 3.13.0 up to the fixed 3.13.19, 4.0.24, 4.1.15, 4.2.10 and 4.3.5 releases, so an authenticated client (CVSS PR:L) that already held the privileged `impersonator` tag can keep publishing messages with a foreign AMQP userid after that privilege is withdrawn. The defect only affects connections that once held `impersonator` and then refresh in place to a same-username OAuth token that no longer grants it, with `rabbit_auth_backend_oauth2` (or an equivalent refresh-capable backend) enabled; a freshly opened connection using the downgraded token correctly refuses the same publish. No public exploit code has been identified at time of analysis, and the practical impact is a stale privilege-revocation gap for an already-privileged session rather than a route for an ordinary user to gain new privileges.
RabbitMQ Management versions 3.13.0 through 3.13.18, 4.0.23, 4.1.14, 4.2.9 and 4.3.4 render an attacker-controlled AMQP queue name as unescaped HTML in an authorization-error reason when the OAuth management UI is enabled, allowing an injected <base> element to retarget the UI's automatic relative refresh. An authenticated attacker holding queue 'configure' permission can therefore cause a management administrator who clicks 'Get Message(s)' on the crafted queue to send their Authorization header to an attacker-controlled endpoint whose CORS policy accepts the management origin. Exploitation requires a stacked set of preconditions - non-default OAuth UI, attacker queue-configure rights, an administrator who can see but cannot read the queue, a victim click, a Content Security Policy lacking base-uri and connect-src, and an attacker endpoint that permits the management origin via CORS - which substantially limits real-world risk; no public exploit identified at time of analysis, and the issue is rated MEDIUM (CVSS 4.0 base 4.5).
RabbitMQ Shovel plugin before 4.3.3, 4.2.9, 4.1.14, and 4.0.23 can write plaintext AMQP credentials from shovel worker GenServer state into crash dump files because the process does not implement the OTP format_status/2 callback; a crash (e.g., network partition) triggers the SASL error handler to serialize the full state, including deobfuscated amqp://user:password@host URIs. Exploitation is not remote: it requires the Shovel plugin to be configured with credentialed URIs, a subsequent crash, and authenticated high-privileged read access to the node's error log or crash dump (CVSS 3.1 PR:H), exposing credentials for the separate upstream/downstream brokers rather than the RabbitMQ node's own data. No public exploit has been identified at time of analysis, and vendor patches are available in the fixed versions.
Atom-table exhaustion in RabbitMQ 4.x lets an authenticated user who holds the 'policymaker' tag crash a broker node by sending a sustained stream of requests (roughly one million) to the Management plugin's /api/global-parameters/:name endpoint, each with a unique name value. The handler passes the URL segment through rabbit_data_coercion:to_atom/1, which uses the unsafe binary_to_atom/2; because Erlang atoms are never garbage collected, every novel name permanently consumes an atom-table slot until the VM aborts. Exposure requires the Management plugin to be enabled and an account above the management tag (but below administrator); it is not reachable unauthenticated, and the assessed impact is availability-only (no confidentiality or integrity loss). No public exploit code or confirmed active exploitation was identified at time of analysis, and the issue is fixed in RabbitMQ 4.0.22, 4.1.14, 4.2.7 and 4.3.1.
Authorization bypass in RabbitMQ's MQTT topic permission handling allows a low-privileged authenticated user to broaden read and write access to topics when an operator-defined permission template embeds the {clientid} variable inside a regex character class. The flaw is an incomplete fix for CVE-2026-44838, where the escaperegexchar/1 function fails to escape the hyphen, enabling a malicious clientid to alter the character class and bypass intended topic authorization. Affected versions include RabbitMQ 4.0.0 through 4.3.2, 4.0.x before 4.0.23, 4.1.x before 4.1.14, and 4.2.x before 4.2.9; the vendor rates this medium severity (CVSS 5.1), and no public exploit code has been identified at time of analysis.
Denial of service in RabbitMQ's management HTTP API lets an authenticated administrator crash the broker by submitting a user (or importing definitions) whose tags list contains roughly one million unique strings; each string is converted to a permanent Erlang atom until the bounded atom table is exhausted and the BEAM node dies. Affected versions are RabbitMQ 4.0.0 through 4.0.21, 4.1.x before 4.1.14, and 4.2.x before 4.2.7, and the attack requires the management plugin to be enabled and reachable plus full administrator privileges, so there is no unauthenticated or low-privilege path. No public exploit code identified at time of analysis, and vendor-released patches are available in 4.0.22, 4.1.14 and 4.2.7; this is a genuine but low-priority availability issue rather than a confidentiality or integrity risk.
Loopback source-address restriction bypass in RabbitMQ's native MQTT and MQTT-over-WebSocket listeners (all releases from 3.13.0 up to the fixed versions 3.13.18, 4.0.23, 4.1.14, 4.2.9 and 4.3.3) allows an authenticated attacker holding valid credentials for a loopback-restricted account to reach that account from a non-loopback address. The flaw only manifests when such a listener runs behind a trusted frontend that speaks PROXY Protocol: the proxy-derived client address is dropped before the MQTT authentication path evaluates the loopback_users setting, so the frontend-to-broker connection is mistakenly judged as loopback. Password authentication itself is not bypassed, CVSS 4.0 base is 6.0 with high attack complexity and a present attack requirement reflecting how deployment-specific the trigger is, no public exploit code has been identified at time of analysis, and the issue is not confirmed actively exploited (no CISA KEV listing).
Authenticated RabbitMQ tenants on affected releases can exhaust broker scheduler CPU and degrade or deny service to all co-tenants by creating a binding with a crafted rjms_erlang_selector LIKE expression on an x-jms-topic exchange. Only deployments running the optional rabbitmq_jms_topic_exchange plugin are exposed, and the attacker needs permissions both to create bindings on that exchange and to publish messages routing through them; no public exploit has been identified at time of analysis and the issue is not in CISA KEV. Impact is availability-only - confidentiality and integrity are unaffected - but a single malicious tenant can degrade a shared broker, so the issue warrants prompt patching rather than emergency escalation.
RabbitMQ 4.0.0 through 4.0.22, 4.1.x before 4.1.14, 4.2.x before 4.2.9, and 4.3.x before 4.3.3 exposes the complete binding topology of a virtual host to any authenticated AMQP 1.0 user, because the HTTP-over-AMQP management handler for GET /bindings (rabbit_amqp_management) returns the binding list without performing the resource-level read/write permission checks that every sibling operation in the same module performs. A low-privileged account with no management, monitoring, policymaker, or administrator tag - and no read/write permission on the relevant exchanges or queues - can enumerate source exchanges, destination queues and exchanges, routing keys, and binding arguments for any vhost it can connect to; only routing metadata is disclosed, not message payloads, and the classic HTTP management API GET /api/bindings is not affected because it validates permissions. Exploitation requires valid broker credentials (unauthenticated remote access is not sufficient), and no public exploit code or confirmed active exploitation was identified at time of analysis; the CVSS 4.0 base score of 6.3 primarily reflects the low-privilege network-reachable precondition with a high subsequent-system confidentiality contribution in the assessing vector, while an independent CVSS 3.1 assessment scores the flaw 6.1-class impact as limited to confidentiality only.
Denial of service in RabbitMQ 4.2.x (4.2.0 through before 4.2.9) and 4.3.x (before 4.3.3) lets an already highly privileged, authenticated user submit crafted Shovel runtime parameters through the Management HTTP API, causing the parser to intern attacker-controlled strings as Erlang atoms until the node-wide atom table is exhausted and the broker can no longer function. Exploitation demands network reach to the Management API plus credentials carrying both the management and policymaker tags, write permission on a vhost, and the non-default rabbitmq_shovel and rabbitmq_shovel_management plugins enabled; because the malicious parameters are persisted durably and re-parsed when workers start, the resource pressure can return after a restart without the attacker being connected. No public exploit code or evidence of active exploitation was identified at time of analysis, and the independent assessment rates this a genuine but low-priority DoS whose high-scoring optics are tempered by those heavy preconditions. Fixed in 4.2.9 and 4.3.3.
RabbitMQ's Federation plugin (3.13.0 up to the fixed 3.13.18, 4.0.24, 4.1.14, 4.2.9 and 4.3.3 releases) validates a federation upstream URI without performing any vhost-access authorization check, letting a principal that holds policymaker rights on one virtual host point an upstream at a different vhost and read and drain messages it has no permission on. With the default ack-mode the source messages are consumed (deleted) rather than copied, so the flaw combines unauthorized cross-vhost disclosure with destructive consumption. Exploitation is authenticated (CVSS PR:L) and contingent on a multi-tenant broker that actually runs Federation and grants untrusted principals policymaker rights, and no public exploit code or CISA KEV entry was identified at the time of analysis, making this a moderate authorization-boundary issue rather than a mass-exploitable emergency.
Expired OAuth2 JWT access tokens are accepted indefinitely by RabbitMQ 4.2.0 through 4.2.8 and 4.3.0 through 4.3.2 when the rabbitmq_auth_backend_oauth2 backend is enabled and the identity provider emits the JWT 'exp' claim as a fractional (float) JSON number rather than an integer. Because the Erlang code guards expiry parsing with is_integer(Exp), both the login-time expiry check and the mid-connection disconnect timer silently fall through for float exp values, so an attacker holding a previously issued, correctly signed token can authenticate with it long after it has expired and keep connections open without being disconnected. The CVSS 4.0 base score is 6.3, but exploitability is sharply conditional - a non-default IdP behavior plus possession of a valid signed token - and no public exploit code has been identified at time of analysis; the issue is fixed in RabbitMQ 4.2.9 and 4.3.3.
LDAP distinguished-name injection in the RabbitMQ rabbitmq_auth_backend_ldap plugin allows a remote, unauthenticated caller to manipulate the DN used for an LDAP bind by supplying a crafted username, because the ${username} placeholder is substituted into user_dn_pattern without RFC 4514 escaping. Impact is limited to integrity (CVSS:4.0 6.3 / CVSS:3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N) and exploitation is narrowly conditioned: the plugin must be enabled, user_dn_pattern must actually contain ${username}, the injected suffix must resolve to a useful directory entry, and the attacker must hold a password valid for that resulting DN. No public exploit code and no confirmed active exploitation were identified at time of analysis; upstream fix commits and patched releases exist, though the advisory's first-fixed version metadata is internally inconsistent for several maintenance lines.
Authenticated RabbitMQ Server 4.2.0 through 4.2.8 and 4.3.0 through 4.3.2 users who hold only 'configure' permission on one exchange can bypass the alternate-exchange authorization check through the AMQP 1.0 management API, silently redirecting unrouteable messages into a target exchange on which they have no write permission. The defect is a missing authorization check (CWE-862) in the PUT /exchanges/:name handler, reachable whenever AMQP 1.0 is enabled - the default in RabbitMQ 4.x - while the equivalent AMQP 0-9-1 channel path already enforces the check. Impact is confined to routing integrity with no confidentiality or availability loss; no public exploit code has been identified at time of analysis, and vendor-released patches are available in 4.2.9 and 4.3.3.
Denial of service via atom exhaustion in RabbitMQ Server when the rabbitmq_auth_backend_oauth2 plugin is enabled and configured with an identity provider that allows user-influenced scope values in signed JWTs. Affected versions include 3.13.0 through 3.13.14, 4.0.x before 4.0.22, 4.1.x before 4.1.11, 4.2.x before 4.2.6, and 4.3.x before 4.3.1. Exploitation requires valid signed tokens bearing novel 'tag:' scope values across many repeated logins, and no public exploit code has been identified at time of analysis; independent assessment rates real-world risk as low due to the non-default plugin, permissive IdP dependency, and high volume of authentications needed.
Administrator-tagged accounts on RabbitMQ can silently delete users that carry the 'protected' tag by calling the management plugin's POST /api/users/bulk-delete endpoint, which skips the protected-user guard that the single-user DELETE /api/users/:name path enforces. The flaw affects RabbitMQ 3.13.0 up to 3.13.14 and 4.0.x, 4.1.x, and 4.2.x releases before 4.0.20, 4.1.11, and 4.2.6, but only when the rabbitmq_management plugin is enabled and only for an attacker who already holds the highest management privilege ('administrator' tag), so the outcome is integrity loss (destruction of hardened service accounts) rather than any escalation of access. No public exploit identified at time of analysis, no confirmed active exploitation (CISA KEV), and no EPSS score was provided; the assessed CVSS:3.1 vector is AV:N/AC:L/PR:H/UI:N/S:U/C:N/I:L/A:N (CVSS 4.0 base 2.1), and realistic risk is confined to insider misuse, a compromised admin credential, or accidental bulk deletion.
Atom table exhaustion in RabbitMQ's management HTTP API lets an authenticated user who holds only the 'management' tag crash the broker's Erlang VM, taking down every vhost and tenant hosted on that node. The 'node' JSON field accepted by PUT /api/queues/:vhost/:name - and by the equivalent exchanges and bindings endpoints - is passed through rabbit_nodes:make/1 to list_to_atom/1 in rabbit_mgmt_util.erl:get_node/1 (lines ~880-885) with no cluster-membership check first, so each unique value permanently leaks one atom until the VM hits system_limit. About 900,000 unique requests are needed rather than a single call, which keeps this a moderate-severity, sustained-abuse availability issue; no public exploit code has been identified at time of analysis, and deployments are fixed by upgrading to 3.13.15, 4.0.20, 4.1.11 or 4.2.6.
Stale OAuth authentication-mechanism preferences can survive a logout in the RabbitMQ management UI on versions 4.2.0 through 4.2.7 and 4.3.0/4.3.1, because the plugin emits a non-ASCII cookie name when it tries to clear the strict_auth_mechanism or preferred_auth_mechanism cookie, and RFC 6265-compliant browsers refuse to delete a cookie whose name is not a valid token. The practical effect is limited to a persisted UI preference carrying across logout/login cycles; there is no code execution, data exfiltration, or confidentiality or availability impact, which is consistent with the NVD CVSS 4.0 base score of 2.3 and with the independent CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:L/A:N assessment. Exploitation requires the management UI to be in active use and a logout/login cycle to occur, and no public exploit code or evidence of active exploitation was identified at time of analysis.
A remote, unauthenticated denial-of-service condition exists in the RabbitMQ stream protocol when the stream plugin is enabled, allowing a client that completes the Tune handshake to declare a frame larger than the negotiated FrameMax and drive excessive memory consumption. Affected deployments are RabbitMQ 3.13.0 through 3.13.14, 4.0.x before 4.0.20, 4.1.x before 4.1.11, and 4.2.x before 4.2.6; the issue is availability-only with no confidentiality or integrity impact, and exploitation requires the non-default stream plugin (and its listener) to be exposed to the attacker. No public exploit code has been identified at time of analysis, and there is no confirmed active exploitation (CISA KEV) associated with this CVE. Independent assessment rates this as a genuine but low-to-moderate-severity DoS issue rather than a high-impact priority.
Unbounded pre-authentication state accumulation in RabbitMQ's Web STOMP WebSocket handler lets an unauthenticated remote client hold connections open with a slow trickle of small frames, causing memory and resource exhaustion on the broker. Only deployments that enable the non-default rabbitmq_web_stomp plugin and expose its WebSocket listener are affected; a single request is not enough, since the attacker must open and sustain many slow connections over time (reflected as AT:P in the assessed vector). RabbitMQ 3.13.0 through 3.13.14, 4.0.x before 4.0.20, 4.1.x before 4.1.11, and 4.2.x before 4.2.6 are vulnerable, and no public exploit code has been identified at time of analysis.
Authenticated denial of service in RabbitMQ brokers running 3.13.0 through the fixed releases 3.13.15, 4.0.20, 4.1.11 and 4.2.6 lets a management user holding the policymaker tag exhaust the Erlang VM atom table and crash the node by submitting an auth_mechanism value containing a very large number of colon-delimited tokens. Exploitation is sharply gated: the Shovel or Federation plugin must be enabled on the target node, and only the privileged policymaker tag can set the auth_mechanism field, so the actor must already be a trusted high-privilege operator rather than an anonymous remote client. Impact is availability-only (node crash), with no data disclosure or modification; no public exploit code has been identified at time of analysis, and vendor-released patches (3.13.15, 4.0.20, 4.1.11, 4.2.6) are available.
RabbitMQ's shovel management resource fails to enforce a policymaker-level check on DELETE operations, so an authenticated user holding the low-privileged 'monitoring' tag - nominally read-only - can delete or restart any dynamic shovel in any vhost visible to that account. The flaw (CWE-862 missing authorization) is reachable over the network with no user interaction and yields high integrity impact against shovel configuration state, though it is bounded by a non-default configuration requiring both the rabbitmq_shovel and rabbitmq_shovel_management plugins to be enabled and by the attacker needing pre-existing credentials plus vhost-scoped visibility. Patches are released in RabbitMQ 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.1; no public exploit code has been identified and there is no confirmed active exploitation (no CISA KEV listing) at time of analysis.
RabbitMQ's Shovel plugin leaks broker credentials on deployments that configure AMQP 1.0 shovels with the username and password embedded directly in the connection URI: in versions prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0 the plugin persists the raw URI instead of sanitizing it the way the AMQP 0-9-1 shovel does via amqp_uri:remove_credentials. Any authenticated user holding the 'monitoring' management tag can read those plaintext credentials from GET /api/shovels or rabbitmqctl shovel_status, and can then reuse them against the remote AMQP 1.0 endpoint. There is no public exploit code identified at time of analysis and no confirmed active exploitation (no CISA KEV listing); the exposure is a passive, read-only credential disclosure whose practical severity is narrowed by the non-default URI-embedded-credential configuration and the monitoring-tag requirement. This is a genuine but modest-priority information-disclosure issue rather than a high-urgency flaw.
RabbitMQ stream-management HTTP API allows an authenticated user holding the management tag and vhost access - but no configure permission on any resource - to create super-streams, which consist of an exchange, N partition stream queues, and their bindings, without the per-resource authorization check the native stream protocol path enforces. This is a genuine but low-impact authorization flaw (CWE-862 missing authorization) rated CVSS 2.1 by the vendor and an assessed CVSS:3.1 of AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N, since the impact is confined to unauthorized integrity changes (persistent resource creation) with no data disclosure or denial of service. Exploitation requires the non-default rabbitmq_stream_management plugin to be enabled and a management-tagged account with vhost access; no KEV listing or public exploit was identified, and vendor fixes are available in 4.0.22, 4.1.11, 4.2.6, and 4.3.0.
Denial of service in RabbitMQ (all server releases prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6 and 4.3.0) allows an authenticated user holding the management tag to burn broker CPU through the supported use_regex=true option on management list endpoints. The caller-supplied ?name= pattern is passed to Erlang/OTP's re:run without a match_limit and executed once per resource in the result set, so on a broker with roughly 5000 queues a single request can consume 12 or more minutes of scheduler time, and parallel requests can saturate the schedulers and degrade availability for all clients. There is no confidentiality or integrity impact, no public exploit code identified at time of analysis, and the risk is bounded by the management-tag requirement, no user interaction being needed but a resource-rich deployment being necessary for the effect to be felt.
Cross-Site WebSocket Hijacking (CWE-1385) in RabbitMQ's Web-MQTT and Web-STOMP plugins allows attacker-controlled JavaScript running in a victim's browser to open an authenticated WebSocket connection to the broker, because the WebSocket upgrade handlers at rabbit_web_mqtt_handler.erl:104 and rabbit_web_stomp_handler.erl:102 never validate the Origin header. The flaw is only reachable under non-default configuration - Web-STOMP with use_http_auth=true, or either plugin with ssl_cert_login=true - where the browser automatically presents the victim's TLS client certificate, letting the attacker inherit the victim's identity; the issue is harmless under the default in-band CONNECT credential setup, so default deployments are unaffected. No public exploit has been identified at time of analysis, but the CVSS:3.1 assessment (AV:N/AC:H/PR:N/UI:R/S:C/C:H/I:H/A:N) rates the confidentiality and integrity impact as high where a vulnerable configuration is in use.
Broken access control in the RabbitMQ management HTTP API lets a user holding only the monitoring tag restart any federation link via DELETE /api/federation-links/.../restart, an operation that should require elevated (management/policymaker/administrator) privileges - thereby disrupting message flow between federated brokers. Affected are RabbitMQ server releases prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.1, but only deployments that enable both the rabbitmq_federation and rabbitmq_federation_management plugins and have at least one active federation link. Exploitation requires an authenticated account carrying the monitoring tag (CVSS v4.0 PR:L), impact is limited to availability of the restarted link, the assessed severity is CVSS 2.3 / CVSS:3.1 AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:L, and no public exploit code or confirmed in-the-wild exploitation was identified at time of analysis.
Memory exhaustion in the RabbitMQ consistent-hash exchange plugin lets an authenticated user with ordinary binding permissions drive broker-wide memory allocation from a single binding. Prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6 and 4.3.0, validate_binding/2 accepts an unbounded integer weight N from the binding routing key and expands it with lists:seq/2; a weight of 100000000 allocates roughly 800 MB on every node, and because the resulting list is written into the exchange's Khepri record it is replicated cluster-wide and reloaded on restart, so a restart does not clear the condition. Exploitation requires the rabbitmq_consistent_hash_exchange plugin to be enabled (it is not enabled by default) plus a low-privilege account holding write on a consistent-hash exchange and read on a queue; no public exploit identified at time of analysis.
Denial of service in RabbitMQ prior to versions 4.2.7 and 4.3.1 allows a remote, authenticated user holding the 'policymaker' tag to crash a broker node by exhausting the Erlang atom table. The runtime-parameters API lookup path coerces the attacker-controlled :component URL segment into a brand-new atom on every request, and because the atom table is bounded and atoms are never garbage collected, roughly one million requests with distinct component values are enough to fill it and bring the node down. Impact is availability-only (no data exposure or modification), exploitation requires high privileges and a very large request volume, and no public exploit code has been identified at time of analysis - the independent assessment rates this a moderate, low-urgency issue and the vendor has released fixed versions 4.2.7 and 4.3.1.
RabbitMQ brokers running the Shovel plugin can write decrypted shovel URIs - including credentials embedded directly in the URI (amqp://user:password@host/) - into the broker log file when DEBUG-level logging is enabled and a shovel configured with src-delete-after=N (autodelete) completes and is torn down. The exposure is confined to log files: anyone who already holds read access to the broker log or a downstream log aggregation pipeline can recover working AMQP credentials, which they can then use to authenticate to the message broker. Exploitation is not remote or unauthenticated (the vendor-adjacent assessment rates it CVSS:3.1 AV:L/AC:L/PR:H/UI:N with high confidentiality impact only), and it requires a chain of non-default conditions: the Shovel plugin enabled, credentials embedded in shovel URIs, DEBUG logging explicitly turned on, and an autodelete shovel. No public exploit code has been identified at time of analysis and the issue is not confirmed actively exploited (no CISA KEV listing); no EPSS score was supplied with the source data.
Denial of service in RabbitMQ affects every server release prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0, where importing a crafted definitions file can exhaust the Erlang atom table and crash the node. The issue is reachable only by an authenticated user holding the RabbitMQ administrator tag: a definitions import containing a vhosts entry with roughly one million unique metadata keys slips under the 20 MB management body limit and is passed by add_vhost/2 into the unsafe rabbit_data_coercion:atomize_keys/1 path (binary_to_atom) with no whitelist or cap, killing the node that processes the request. Impact is limited to availability loss on a single node (no disclosure or tampering), exploitation is gated behind administrator privileges, and no public exploit code was identified at time of analysis; vendor-released fixes are available in the versions listed above.
Memory exhaustion in RabbitMQ Server (versions prior to 4.1.11, 4.2.6, and 4.3.0) lets a caller holding the management tag crash or severely degrade a broker by submitting a stream partition request whose count is unbounded - validate_partitions only enforces a lower bound of 1, so a value such as lists:seq(0, 500000000) drives roughly 8GB of allocation. Exploitation requires three conditions to hold simultaneously: the rabbitmq_stream_management plugin must be enabled (it is off by default), the caller must carry the management tag, and the caller must have access to the target vhost; with those met, impact is availability-only (CVSS 5.9, PR:H, no confidentiality or integrity effect) and can cross tenant boundaries on a shared broker. No public exploit code has been identified at time of analysis and there is no confirmed active exploitation, keeping this a genuine but bounded availability risk rather than an emergency.
Authenticated CPU exhaustion in RabbitMQ Server prior to 4.2.7 and 4.3.1 lets an AMQP 1.0 consumer that holds both read and write permission on a stream queue drive substantial backtracking work in the broker's regex engine: a crafted LIKE filter built from roughly two thousand overlapping '%_' wildcard pairs, combined with long message property values, forces about 100-200 ms of CPU to be consumed per delivered message. The impact is bounded resource amplification rather than a node crash or hang, consistent with a low-severity denial-of-service rating (CVSS 4.0 base 2.3; independent assessment CVSS 3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:N/I:N/A:L), and no public exploit code has been identified at time of analysis. Exposure is limited to deployments that actually use AMQP 1.0 with stream queues and SQL filter expressions; systems not using that combination are unaffected.
Cross-tenant information disclosure in RabbitMQ's management HTTP API lets any authenticated user holding the 'management' tag read Raft quorum-queue status - leader, members, term, commit index - for queues in vhosts they cannot access, because the /api/queues/quorum/:vhost/:queue/status handler authorizes only the management tag rather than the target vhost. Affected are RabbitMQ deployments running the management plugin at versions prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0, with impact confined to read-only exposure of queue names and cluster topology in multi-tenant setups. No public exploit identified at time of analysis; EPSS and KEV signals are absent, and the assessed CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:N/A:N) rates this low severity.
An authenticated denial-of-service condition in RabbitMQ Server allows a stream-protocol user with read access to any stream to crash the broker node by exhausting the Erlang atom table. The flaw affects RabbitMQ Server releases prior to 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.1, but only when the rabbitmq_stream plugin is enabled - deployments without that plugin are not exposed. Exploitation requires valid stream credentials (CVSS 4.0 vector shows PR:L, and the assessed vector is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H) and the repeated submission of many frames carrying distinct chunk_selector values, which is why the severity is scored as a moderate-priority availability issue rather than a critical remote-code flaw. No public exploit code or confirmed active exploitation has been identified at time of analysis.
Authenticated tenants can bypass operator-configured per-user and per-vhost connection limits in RabbitMQ by connecting to the stream protocol listener on port 5552 instead of the AMQP listener on port 5672, allowing resource-exhaustion conditions that the operator believed were prevented. The flaw affects RabbitMQ Server releases prior to 4.2.7 and 4.3.1 when the rabbitmq_stream plugin is enabled, and the code path was fixed in those two maintenance releases. Exploitation requires valid stream-protocol credentials and an environment where per-user or per-vhost connection caps are actually relied upon as a tenant-isolation control; no public exploit code was identified at time of analysis and there is no confirmed active exploitation (CISA KEV).
Authenticated RabbitMQ users that hold the 'monitoring' tag can erase a node's authentication-attempt counters by sending DELETE /api/auth/attempts/:node through the Management plugin HTTP API, removing a signal that operators would use to notice brute-force activity. Only deployments running RabbitMQ prior to 4.1.13, 4.2.7 or 4.3.0 with the Management plugin enabled and monitoring credentials issued to a non-administrative or untrusted account are exposed, and exploitation requires the attacker to already possess that valid account. The impact is limited to in-memory metrics (no log or audit-record deletion) and no public exploit code has been identified at time of analysis; EPSS data was not supplied and the issue is not in CISA KEV, consistent with its very low assessed severity.
Atom-table exhaustion in RabbitMQ's x-jms-topic exchange lets an authenticated low-privilege AMQP user crash an entire broker node in fewer than 100 binding declarations, turning a vhost-confined account into a cross-tenant denial of service. The flaw is reachable only when the bundled rabbitmq_jms_topic_exchange plugin is enabled - standard in any JMS deployment - and the attacker holds read permission on an x-jms-topic exchange plus write permission on a queue, or configure rights to declare both; it also requires a raw AMQP client, because the broker does not enforce the client-side selector compilation that the Java JMS client performs. Fixed in RabbitMQ 3.13.15, 4.0.20, 4.1.11, 4.2.6 and 4.3.0; no public exploit identified at time of analysis and no CISA KEV listing, though the attack needs no user interaction and is network-reachable, with an assessed CVSS 3.1 score of AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H.
Path traversal in the RabbitMQ tracing plugin lets a user holding the administrator tag write a file to an arbitrary filesystem location writable by the rabbitmq OS user, because the trace consumer builds its output path as filename:join(TraceDir, Name ++ ".log") from the unvalidated Name parameter of PUT /api/traces/:vhost/:name. Exploitation is an authenticated, administrator-only operation (CVSS vector PR:H) and requires that the rabbitmq_tracing plugin is explicitly enabled and that the target directory is already writable by the broker's OS account, so the realistic scenario is insider or post-compromise abuse rather than an externally reachable flaw. Impact is limited to integrity of local files (I:L, C:N/A:N) and is further constrained by the mandatory .log suffix, which restricts writes to .log-suffixed targets and makes any escalation to code execution opportunistic; no public exploit identified at time of analysis, and the issue is rated 2.1 (CVSS 4.0), consistent with a low-priority, high-privilege finding. Fixed versions are 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.1.
TLS certificate validation is completely bypassed in the RabbitMQ Java client library (`com.rabbitmq:amqp-client`) prior to version 5.33.0 when applications call `ConnectionFactory.useSslProtocol()` or `useSslProtocol(String)`, because these methods silently install `TrustEverythingTrustManager` and leave hostname verification disabled. A network-positioned attacker can present any certificate - including self-signed or null-chain - to impersonate the RabbitMQ broker and decrypt or modify all AMQP traffic, including plaintext credentials transmitted via PLAIN SASL on default port 5672. A verified proof-of-concept is publicly available in GHSA-5m9f-rphj-c435; no confirmed active exploitation (CISA KEV) has been recorded at time of analysis.
Denial of service in the RabbitMQ Java client library (com.rabbitmq:amqp-client ≤ 5.30.0) allows a malicious or compromised AMQP broker to forcibly terminate any active client connection by sending a crafted malformed frame sequence. The flaw in CommandAssembler.consumeBodyFrame subtracts a peer-controlled body-frame payload length before validating it fits within the declared body size, driving remainingBodyBytes negative and triggering an unhandled UnsupportedOperationException - a legacy stub - rather than a proper MalformedFrameException, causing AMQConnection to perform a hard connection shutdown. A PoC is referenced in the GHSA advisory; no active exploitation is confirmed in CISA KEV.
Authenticated RabbitMQ users can bypass authorization controls on passive AMQP 0-9-1 declare operations, exposing internal broker topology metadata across all affected release branches (3.13.x, 4.0.x, 4.1.x, 4.2.x). The missing authorization check on passive queue.declare and exchange.declare allows any user with vhost connectivity to enumerate queue and exchange names and read live message and consumer counts without requiring elevated permissions. No public exploit code has been identified and the vulnerability is not in CISA KEV; however, the low exploitation complexity, authentication-only prerequisite, and broad affected version range meaningfully elevate real-world exposure risk in multi-tenant or shared-credential deployments.
RabbitMQ Server prior to 4.2.6 fails to cancel or reauthorize existing AMQP 0-9-1 consumers when an OAuth token expires or when connection.update_secret reduces token scopes, allowing an authenticated consumer to continue receiving messages it is no longer authorized to access. The broker evaluates authorization only at consumer registration time, not at message delivery time, creating a persistent authorization bypass window for as long as the connection remains open. No public exploit exists at time of analysis, but the CVSS 4.0 vector assigns high subsequent-system confidentiality impact (SC:H), reflecting meaningful data-access risk in OAuth-governed or multi-tenant deployments.
Stored cross-site scripting in the RabbitMQ federation management plugin allows any user with federation upstream or policy configuration privileges to execute arbitrary JavaScript in the browser of an administrator viewing the Federation Status page. The rabbitmq_federation_management plugin renders the consumer_tag field without HTML escaping, making it a persistent injection vector that fires passively when a victim navigates to the page. No public exploit code and no CISA KEV listing are identified at time of analysis; the CVSS 4.0 score of 5.7 reflects meaningful but constrained risk due to the high-privilege prerequisite.
RabbitMQ is a multi-protocol messaging broker. Rated medium severity (CVSS 4.8), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.
RabbitMQ is a multi-protocol messaging broker. Rated medium severity (CVSS 5.4), this vulnerability is remotely exploitable, low attack complexity. Public exploit code available.