Erlang
Monthly
Hostname verification in the Erlang library ssl_verify_fun (versions 1.0.1 through 1.1.7) mishandles partial-label wildcard certificate identifiers, letting a certificate such as f*.example.net be accepted for f.evil.example.net. A man-in-the-middle holding such a certificate from a CA the victim trusts could impersonate the peer, but only where ssl_verify_fun is the sole hostname check - clients with server_name_indication disabled, TLS servers using it to check client certificates, direct callers of verify_cert_hostname/2, or Erlang/OTP older than 20.0, since OTP 20.0+ with SNI set rejects the mismatch in ssl first. Fixed in 1.1.8; no public exploit identified at time of analysis, though a detailed proof-of-concept procedure is published in the advisory.
Password-protected private-key exports produced by the Erlang/Elixir `jose` library between 1.10.0 and 1.11.12 are encrypted with a hardcoded, drastically under-strength key-derivation step, so anyone who obtains such an exported blob can crack the export password offline at roughly 300 times less cost than modern guidance intends and recover the full private key. Only the password-based export path is affected (JOSE.JWK.to_der/2, jose_jwk:to_der/2, the PEM equivalents and their _file variants); the attack requires possession of the exported DER/PEM file and succeeds only where the export password is weak or moderate, since a long randomly generated password still resists 2048 PBKDF2 iterations. EPSS is very low (0.06%) and there is no KEV listing, but a public proof-of-concept script accompanies the upstream advisory; a public PoC reference exists and demonstrates parameter extraction plus dictionary recovery, though it is not verified here as working exploit code. The vendor fixed the parameters in 1.11.13, and the CVSS vector indicates no privileges are required (PR:N), with the practical gating factors being blob exposure and password strength rather than any network-reachable interface.
Memory exhaustion in the Erlang hackney HTTP client (2.0.0-beta.1 through 4.8.x) lets any server the client requests force the connection process to buffer an entire response body with no size bound; when {auto_decompress, true} is set, a small compressed body is additionally inflated in one zlib call, multiplying the allocation. The default hackney:request/5 and hackney:body/1 paths buffer the full body, so unauthenticated remote attackers who control or influence the target server (directly, via redirect, or via an SSRF-style URL) can crash or stall the calling BEAM process, giving availability-only impact. No public exploit code was identified at time of analysis and there is no KEV confirmation; 4.9.0 introduces a max_body_size option (default 512 MiB) that caps buffering and returns {error, body_too_large}.
Improper certificate validation in the Erlang HTTP client hackney (1.24.0 through 4.8.x) lets an on-path attacker impersonate a server that an application has pinned to a private certificate authority. Because hackney adds its own {partial_chain, fun hackney_ssl:partial_chain/1} to every verify_peer configuration and OTP honours that callback over a caller-supplied cacerts/cacertfile trust store, a chain ending in any certifi-bundled public root can be accepted as the trust anchor; the attacker still needs a man-in-the-middle position and a publicly trusted certificate for the exact pinned hostname that satisfies the hostname check, so only non-default private-CA pinning deployments are exposed. No public exploit identified at time of analysis and no CISA KEV entry, though the issue is triaged as act_now and fixed in hackney 4.9.0.
Unauthenticated remote attackers can crash an Erlang node running the Dropbox esaml SAML library (versions 0.1.0 and later) by sending a crafted SAMLResponse to the SAML assertion-consumer (ACS) or single-logout (SLO) endpoint. Because esaml_binding:decode_response/2 hands the decoded XML to xmerl_scan:string/2 before any signature check, every distinct element name, attribute name, and namespace prefix in the document is interned as a permanent Erlang atom; a few dozen requests carrying documents with thousands of unique names exhaust the roughly one-million-entry atom table and abort the VM. The CNA rates this CVSS 4.0 at 8.7, while independent assessment aligns with a CVSS:3.1 vector of AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - pure availability impact with no confidentiality or integrity loss; no public exploit code was identified at time of analysis and there is no CISA KEV listing, though the flaw is trivially reachable by anyone who can POST to a SAML endpoint.
Unauthenticated remote denial of service in the Erlang SAML library esaml (0.1.0 and later) allows an attacker to abort an Erlang node by exhausting its atom table through unsigned LogoutResponse messages posted to a Service Provider's single-logout endpoint. Because esaml_sp:validate_logout_response/2 only verifies a signature when one is present, an unsigned message reaches esaml:decode_logout_response/1, where status_code_map/1 converts each unrecognized StatusCode into a permanent atom with list_to_atom/1 - roughly one million distinct status values (the VM's default atom-table ceiling) are enough to crash the node. The CNA scored this CVSS 4.0 8.2 with the AT:P attack-requirement metric; the practical barrier is volume and time rather than skill, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Denial of service in the Erlang OTP ssl application allows a malicious or man-in-the-middle TLS 1.3 server to crash the node-global session-ticket store on a connecting client, and repeated crashes can exhaust the ssl supervisor restart intensity and take down TLS for every connection on that node. The victim must be a TLS 1.3 client running OTP 23.3 through the fixed releases with session_tickets set to auto (automatic ticket storage and resumption); the crash does not occur when the bogus ticket is received but on the next automatic resumption attempt, and it requires the client to initiate the outbound connection, which is reflected in the assessed AT:P attack-requirement metric and a CVSS 3.1 base of 5.9 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) despite the vendor's CVSS 4.0 score of 8.2. No public exploit code has been identified at time of analysis and there is no CISA KEV listing, but vendor patches and upstream commits are available. Reported by the Erlang Ecosystem Foundation (EEF) and tracked as EUVD-2026-101384.
A path traversal flaw in rebar3, the standard build and dependency-management tool for Erlang/OTP, lets a malicious Hex package publisher cause rebar3 to delete an arbitrary directory and write package files into it whenever a developer or CI job fetches that package's dependencies. The attack abuses an unvalidated 'app' field in Hex registry dependency metadata: rebar3 treats that field as the dependency directory name, so a value such as '../../../../target' resolves outside the project's _build tree and is then removed with rm -rf before the fetched package is moved into place. Only rebar3 3.7.0-rc1 through 3.27.1 is affected, exploitation requires user interaction (a developer running rebar3 get-deps against a project that pulls in the malicious release, directly or transitively), and because the deletion occurs before the dependency's rebar.config.script is evaluated and get-deps compiles nothing, the practical impact is destructive file deletion and overwrite rather than immediate code execution; no public exploit code has been identified at time of analysis, and the public hex.pm registry added validation for the field on 2026-10-12, leaving private or self-hosted Hex registries as the main residual exposure.
Denial of service in the Erlang language bindings of Apache Thrift before 0.25.0 allows remote attackers to exhaust server resources through unbounded allocation, degrading or crashing the affected service. The flaw is CWE-770 (Allocation of Resources Without Limits or Throttling) and carries a CVSS v4.0 base score of 8.2; our independent assessment scores it CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H, reflecting a high-availability-only impact that requires a specific crafted message structure (AT:P) rather than arbitrary traffic. Only deployments running a Thrift server compiled with the Erlang bindings and exposed to attacker-reachable network traffic are affected; users of the C++, Java, Python, Go and other bindings are not impacted, and no public exploit code was identified at time of analysis.
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.
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.
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.
The RabbitMQ management plugin (rabbit_mgmt_cors.erl) reflects an attacker-controlled Origin header straight back in Access-Control-Allow-Origin while also returning Access-Control-Allow-Credentials: true, so when an operator has configured cors_allow_origins = "*" a hostile web page can make a signed-in administrator's browser issue authenticated, state-changing requests to the management HTTP API. Exploitation is conditional rather than automatic: it requires the non-default wildcard CORS setting, a live cached HTTP Basic-auth administrator session, and the administrator being lured to the attacker's page (user interaction), and no public exploit code has been identified at time of analysis; assessed severity is CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N. The issue affects the management plugin in RabbitMQ releases prior to 3.13.17, 4.0.22, 4.1.13 and 4.2.6.
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.
Denial of service in Erlang/OTP's ASN.1 OBJECT IDENTIFIER decoders allows a remote, unauthenticated attacker to stall TLS-processing services by sending a crafted certificate during the handshake. Erlang/OTP releases from OTP 17.0 up to the fixed versions OTP 27.3.4.18, OTP 28.5.0.7 and OTP 29.1.1 are affected whenever the service parses a peer's X.509 certificate - the default for TLS clients (which always parse the server certificate) and for mutual-TLS servers - because the vulnerable BER OID decoder runs before signature and trust-chain verification, so an untrusted self-signed certificate is sufficient to trigger it. A single crafted OID with one very large arc (roughly 262 KB of continuation bytes) burns about 13 seconds of CPU, so sustained denial of service requires repeated connections; no public exploit code identified at time of analysis, and the impact is availability only (vendor CVSS 8.2; independently assessed as CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).
Authenticated remote attackers can exhaust node memory on Erlang/OTP SSH daemons by repeatedly opening "session" channels that never receive a shell, exec, or subsystem handler, eventually driving the BEAM emulator out of memory and terminating it - which kills every application sharing that node, not just the SSH service. The flaw (CWE-770) affects OTP 17.0 through 27.3.4.18, 28.5.0.7, and 29.1.1 (ssh 3.0.1 through 5.2.11.13, 5.5.2.6, and 6.0.6); an attacker must be able to complete SSH authentication first, but no user interaction, special configuration, or valid file/credential access is required, and CVSS scores it 7.1 (CVSS 4.0 availability-high, PR:L). No public exploit identified at time of analysis, and vendor-released patches are available. The documented max_channels daemon option does not mitigate the attack, so operators cannot rely on it as a stopgap.
Erlang/OTP's ssl application in affected releases (OTP 22.2 through the fixed 27.3.4.18, 28.5.0.7 and 29.1.1) will complete a TLS 1.3 client handshake against any peer that answers with an unsolicited pre_shared_key extension, allowing that peer to impersonate the intended server while holding no certificate, no private key and no prior session. Because the bogus resumption flag short-circuits certificate handling, ssl:connect returns {ok, Socket} even though certificate path validation, verify_fun, hostname verification, partial_chain, CRL checking and OCSP stapling are all skipped; an unauthenticated network-positioned attacker (man-in-the-middle, hijacked route/DNS, or a server the client is lured into contacting) can exploit this, and clients restricted to TLS 1.2 are not affected. A vendor patch is available and no public exploit code has been identified at time of analysis.
Authentication bypass in Erlang/OTP inets httpd allows remote unauthenticated attackers to read files inside mod_auth-protected directories across OTP 17.0 through 29.0 by prefixing the request URI with an extra slash. The inets URI normalizer preserves doubled slashes that RFC 3986 dot-segment removal does not collapse, causing mod_auth's directory-protection regex to silently fail to match while the OS transparently serves the protected file. No CISA KEV listing or public exploit code has been identified at time of analysis; CVSS 4.0 scores this 8.2 with high confidentiality impact contingent on mod_auth being explicitly configured.
Unauthenticated file disclosure in Erlang/OTP's inets httpd allows remote attackers on case-insensitive filesystem deployments to read files inside mod_auth-protected directories by requesting them with differently-cased path segments. The flaw spans OTP 17.0 through 29.x (inets 5.10 through 9.7.x) and stems from mod_auth's path-matching regex omitting the caseless flag, causing authentication checks to be silently bypassed when request path casing differs from the configured directory name while the filesystem resolves both to the same file. No public exploit code or active exploitation has been identified at time of analysis, and deployments on case-sensitive filesystems - the default on Linux - are fully unaffected by this vulnerability.
The BEAM runtime in Erlang/OTP crashes when a remote attacker sends a crafted packet to any exposed TCP port using the inet driver with {packet,4} framing, exploiting a signed integer overflow in packet length calculation inside packet_parser.c and inet_drv.c. Affected deployments span OTP release lines 17 through 29, with vendor-released patches available (27.3.4.17, 28.5.0.6, and 29.0.6); no active exploitation is confirmed in CISA KEV and no public exploit code has been identified at time of analysis. The vendor explicitly characterizes remote code execution as 'extremely unfeasible,' making denial-of-service via VM crash the realistic worst-case impact.
Erlang/OTP's inets HTTP server (httpd) fails to enforce an administrator-configured request body-size limit when processing chunked transfer-encoded requests, enabling unauthenticated remote attackers to exhaust server memory and cause denial of service. Affected OTP branches span 17.x through 27.3.4.16, 28.x through 28.5.0.5, and 29.x through 29.0.5, covering inets versions 5.10 through 9.7.1. No public exploit code has been identified and the CVE is not listed in the CISA KEV catalog, but the zero-authentication, low-complexity network attack path makes this an operationally straightforward DoS risk for any deployment exposing inets httpd to untrusted clients.
Request smuggling in Erlang OTP inets (versions 17.0 through 29.x) arises when the httpd server sits behind a Content-Length-preferring reverse proxy: inets frames the request body by chunked Transfer-Encoding and silently discards a co-present Content-Length header, while the front-end proxies request boundaries by Content-Length, producing a classic CL.TE desync. An unauthenticated network attacker in this topology can inject a crafted prefix into a subsequent victim's HTTP request, potentially enabling session hijacking, credential theft, or cache poisoning against other users of the same back-end. No public exploit has been identified at time of analysis, the vulnerability is not listed in CISA KEV, and vendor patches are available for the OTP 27.x, 28.x, and 29.x release branches.
Remote unauthenticated attackers can exploit Erlang/OTP's built-in inets HTTP server across OTP versions 22.2 through 29.0 to conduct HTTP Request Smuggling by sending headers with whitespace before the colon - a malformed construct the server silently discarded rather than rejecting as mandated by RFC 7230 Section 3.2.4. When inets is deployed behind a front-end proxy or load balancer that interprets such headers differently, the resulting parsing discordance creates a desynchronized request boundary exploitable for session hijacking, authentication bypass, or cache poisoning. No public exploit has been identified at time of analysis; vendor-released patches are available across all three affected OTP release branches.
HTTP request smuggling in Erlang/OTP's built-in inets httpd server allows unauthenticated remote attackers to inject arbitrary HTTP headers and poison request pipelines in deployments fronted by a reverse proxy. The root cause is a longstanding absence of obs-fold support: any CRLF followed by a whitespace octet (SP or TAB) is silently parsed as a new header rather than a header continuation, causing proxy-backend disagreement on request boundaries. Affected versions span OTP 17.0 through the patched releases (27.3.4.17, 28.5.0.6, 29.0.6), with vendor patches now available via the Erlang GitHub security advisory. No public exploit code or CISA KEV listing exists at time of analysis.
Unbounded memory exhaustion in the Erlang/OTP inets httpc HTTP client allows any server the client connects to - including via redirect or man-in-the-middle - to crash the BEAM VM by returning an arbitrarily large volume of response headers. The root cause is that max_header_size defaults to the atom nolimit and the header accumulation loop in httpc_response:parse_headers/6 collects all header data into an in-process list before any size check fires. A proof-of-concept server delivering 100,000 headers of ~4,000 bytes each consumed over 13 GB of RAM in under 30 seconds; no public exploit code has been separately released but the PoC is embedded in the official advisory, and vendor patches are available for OTP 27, 28, and 29 branches.
Erlang/OTP's inets HTTP server (httpd) is vulnerable to a slow-body resource exhaustion attack exploitable by unauthenticated remote attackers across OTP versions 17.0 through 29.0. The request handler cancels its active timeout after successfully parsing request headers, then re-arms the socket for body data without installing any replacement timer, allowing an attacker to open connections with syntactically valid headers and a large Content-Length and then stall indefinitely - permanently occupying a worker process per connection. Vendor patches are available for the OTP 27.x, 28.x, and 29.x branches; no public exploit code or CISA KEV listing has been identified at time of analysis.
Unauthenticated denial of service in Erlang/OTP's inets httpd allows any remote attacker to exhaust a server's process pool, memory, and file descriptors by holding open an unlimited number of TCP connections. The flaw affects all inets httpd deployments across OTP 17.x through 29.x that do not explicitly configure the max_clients option; when that option is absent, a type-comparison defect caused by Erlang's term-ordering rules makes the connection-count guard unconditionally pass, accepting connections without bound. Vendor patches are available in OTP 27.3.4.17, 28.5.0.6, and 29.0.6; no public exploit code or CISA KEV listing has been identified at time of analysis.
Denial of service in Erlang/OTP's TLS handshake allows remote unauthenticated attackers to crash the BEAM VM by sending a crafted X.509 certificate chain. The vulnerability affects OTP versions 26.2 through 29.0.3 and specific patch releases of 27 and 28, exploiting unbounded growth of the policy tree during path validation. No active exploitation or public exploit code is known at this time, but the attack is automatable and has a high CVSS score.
Erlang/OTP nodes that decode External Term Format (ETF) from untrusted sources can be aborted outright by a single malformed term, in versions from OTP 27.0 up to but not including the fixed releases OTP 29.0.4, 28.5.0.4 and 27.3.4.15 (erts 15.0 up to 17.0.4, 16.4.0.4 and 15.2.7.11). The BIT_BINARY_EXT tag (77) handler accepts an encoding with zero length and zero trailing bits, causing an unsigned underflow in the computed bitstring size; the resulting value near 2^64 is handed to the allocator, which terminates the entire VM with an abort rather than raising a catchable Erlang exception. The vulnerability is unauthenticated (CVSS 4.0 vector PR:N) but requires the target application to feed attacker-controlled bytes into binary_to_term/1,2 or enif_binary_to_term(), an application-design precondition reflected as AT:P in the vendor vector and assessed as AC:H in our CVSS 3.1 evaluation; impact is availability-only (C:N/I:N/A:H). There is no indication of active exploitation (not in CISA KEV; SSVC exploitation: none) and EPSS is low at 0.32% (24th percentile), and no public exploit code has been identified at time of analysis. Vendor-released patches are available.
Remote code execution and denial of service are possible against Erlang/OTP nodes that run the megaco application with the optional flex C-driver scanner, because a single text-encoded H.248/Megaco message carrying an oversized property parm name overflows a fixed 512-byte error buffer and corrupts live pointers inside the scanner driver struct. Affected are OTP releases from 17.0 up to the 29.0.4, 28.5.0.4 and 27.3.4.15 fixes (megaco 3.17.1 through 4.9.1, 4.8.3.1 and 4.7.2.2) where {scanner, flex} is configured; exploitation requires only network reachability to the megaco transport port, with no authentication or user interaction (vendor CVSS:4.0 8.3; independent assessment CVSS:3.1 AV:N/AC:H/PR:N/UI:N/C:N/I:L/A:H). Reliable code execution is not confirmed and depends on struct/heap-layout grooming, builds compiled with _FORTIFY_SOURCE abort with SIGABRT (denial of service only), no public exploit code was identified at time of analysis, EPSS is 0.73% (51st percentile), and CISA SSVC rates exploitation as none with automatable as no.
An on-path attacker can force an Erlang/OTP TLS 1.2 or DTLS client to accept an anonymous cipher suite not offered by the client, bypassing certificate validation and enabling full traffic decryption and manipulation. This affects OTP versions 17.0 through prior to 27.3.4.15, 28.5.0.4, and 29.0.4. The vulnerability is resolved in patched releases; no active exploitation or public proof-of-concept is known at this time.
Uncontrolled recursion in the Erlang/OTP ssl application when processing a crafted TLS/DTLS certificate chain allows remote attackers to exhaust memory and crash the BEAM node. Affects OTP versions 23.2 to before 27.3.4.15, 28.5.0.4, 29.0.4 (ssl 10.2 to before 11.2.12.11, 11.6.0.4, 11.7.4). No user interaction or authentication required, making this a pre-authentication denial-of-service risk for any TLS
Remote denial of service in Erlang/OTP's ssl application (dtls_packet_demux module) lets an unauthenticated attacker crash every active DTLS session on a listener by rapidly reconnecting from the same source IP and port. Because a single shared demux gen_server routes all UDP datagrams for a listener, its TOCTOU-induced crash takes down all clients, not just the attacker's, and can be repeated for a persistent outage. No public exploit is identified at time of analysis, and the issue is not listed in CISA KEV.
Denial of service in the Erlang/OTP ssl application (OTP 22.2 through 29.0.3, and the 28.5.x/27.3.x maintenance branches) lets an unauthenticated remote attacker permanently disable TLS 1.3 session ticket handling on a listener with a single crafted ClientHello. Because the pre-shared key extension's identity list and binder list are not length-checked before being handed to the session ticket handler, a mismatched OfferedPreSharedKeys record crashes that process, causing all subsequent TLS 1.3 handshakes to fail at ticket issuance until the ssl application is restarted. No public exploit identified at time of analysis and it is not on CISA KEV, but the CVSS 4.0 base score of 8.2 reflects the trivial, pre-authentication trigger.
Credential leakage in Erlang/OTP's inets httpc client (versions 17.0 through 29.0.2, 28.5.0.2, and 27.3.4.13) allows attacker-controlled servers to harvest Authorization and Proxy-Authorization headers by issuing cross-origin 3xx redirects. Because httpc_response:redirect/2 only updates the host field and copies all other headers verbatim - and autoredirect defaults to true - any httpc caller using HTTP Basic auth or URL userinfo silently forwards credentials to the redirect target. No public exploit identified at time of analysis, but the fix has been published upstream and tagged in vendor-released OTP patch versions.
Authentication bypass in Erlang/OTP's TLS distribution module (inet_tls_dist) lets any attacker holding a TLS certificate signed by a CA in the node's trust store gain full Erlang distribution access, including remote code execution via rpc:call/4 and code:load_binary/3. The flaw stems from check_ip/1 inspecting the local socket address (inet:sockname/1) instead of the peer's address (inet:peername/1), so the LAN-allowlist subnet comparison always matches. No public exploit identified at time of analysis, but the one-line root cause is fully disclosed in the upstream fix commit.
Denial of service in Erlang/OTP erts (inet_drv SCTP handler) lets unauthenticated remote attackers crash the BEAM VM by sending a single crafted SCTP ERROR chunk to a listening SCTP port. The flaw is a stack-based buffer overflow (CWE-121) in sctp_parse_error_chunk, with the publicly disclosed advisory from the Erlang Ecosystem Foundation (EEF) and an upstream commit confirming the fix; no public exploit identified at time of analysis, and the overflow only permits writing 16-bit values interleaved with a fixed tag, limiting impact to DoS plus minor memory disclosure.
TLS server impersonation in Erlang/OTP's public_key library lets a name-constrained subordinate CA forge a trusted identity for hostnames outside its permitted DNS subtree. By chaining a nameConstraints enforcement gap with a legacy CommonName fallback in pkix_verify_hostname/3, an attacker holding a DNS-restricted intermediate (e.g. permitted;DNS:allowed.example.com) can issue a SAN-less leaf whose CN is an out-of-scope host (e.g. victim.example.com) and have a stock ssl:connect client with verify_peer accept it. It affects OTP 19.3 through the fixed releases (public_key 1.4 onward) and is rated CVSS 4.0 7.6; there is no public exploit identified at time of analysis and it is not on CISA KEV.
Certificate chain forgery in Erlang/OTP's public_key application (pubkey_cert module) lets a non-CA end-entity certificate act as an intermediate issuer, allowing an attacker holding such a certificate's private key to sign forged leaf certificates for arbitrary identities that public_key:pkix_path_validation/3 will accept. This breaks server identity verification for TLS clients and client-certificate verification for mTLS servers across any application using the OTP ssl stack with the default verifier. Tracked as CWE-295 with a CVSS 4.0 base score of 7.0 (subsequent-system confidentiality and integrity rated High); no public exploit identified at time of analysis and it is not listed in CISA KEV, with the only available code being the vendor fix commits.
Authorization bypass in Erlang OTP's inets HTTP server allows unanauthenticated remote attackers to execute CGI scripts protected by directory-level access controls. The vulnerability stems from a path mismatch where mod_auth validates access against DocumentRoot-relative paths while mod_cgi executes scripts at ScriptAlias-resolved paths outside DocumentRoot. With CVSS 8.3 (AV:N/AC:L/PR:N), the attack requires no authentication and low complexity but depends on specific ScriptAlias configuration
Erlang OTP public_key module (versions 1.16 through 1.20.3 and 1.17.1.2) fails to cryptographically verify OCSP responder certificate signatures, allowing network attackers to forge OCSP responses with self-signed certificates bearing matching issuer names and OCSPSigning extended key usage. This bypasses certificate revocation checks in SSL/TLS clients using OCSP stapling, enabling man-in-the-middle attackers to present revoked certificates as valid and intercept sensitive communications. Vendo
A critical HTTP Request Smuggling vulnerability exists in Erlang OTP's inets httpd module that allows attackers to desynchronize front-end and back-end servers by exploiting inconsistent Content-Length header parsing. The vulnerability affects Erlang OTP versions from 17.0 through 28.4.0 (inets 5.10 through 9.6.0) and enables attackers to bypass security controls, potentially poisoning web caches or accessing unauthorized resources. While not currently listed in CISA KEV or showing high EPSS scores, the vulnerability has a CVSS 4.0 score of 7.0 and could lead to significant security boundary violations in production environments using affected Erlang-based web services.
Erlang/OTP SSH server allows unauthenticated remote code execution by exploiting a flaw in SSH protocol message handling, enabling unauthorized system access with CVSS 10.0.
ECDSA JWS signature malleability in erlang-jose (potatosalad:jose) 1.0.0 through 1.11.12 lets anyone holding a single legitimately issued ES256/ES256K/ES384/ES512 token produce multiple distinct signature byte strings that all verify against the same key, because verify/4 never checks the RFC 7518 §3.4 fixed signature length. It cannot forge new payloads or impersonate a signer - the underlying (r, s) pair is unchanged - but it defeats controls that assume a token or signature is unique, such as token-revocation-by-hash, replay/idempotency caches and deduplication keyed on raw signature bytes; applications that enforce uniqueness via a claim such as jti are not meaningfully affected. Exploitation requires an already-valid token as input (assessed vector AV:N/PR:L), a demonstration PoC reference ships with the vendor advisory but it is not verified as working exploit code against third-party deployments, EPSS is 0.09% (1st percentile), there is no CISA KEV listing, and the vendor released a fix in 1.11.13.
Memory-exhaustion denial of service in the erlang-jose JOSE/JWE library for Erlang and Elixir (versions 1.0.0 through 1.11.12) lets a remote, unauthenticated attacker inflate a few-kilobyte JWE token into hundreds of megabytes or gigabytes on the decrypting node and crash the BEAM. When a token carries the optional zip: "DEF" header, jose_jwe_zip:uncompress/2 feeds the entire attacker-controlled plaintext to zlib:inflate/2 with no output-size or inflation-ratio bound, and this happens automatically inside jose_jwe:block_decrypt/2 (JOSE.JWE.block_decrypt/2) before the recipient can inspect or reject the payload; with RSA-OAEP or ECDH-ES key management the attacker only needs the recipient's public key and no secret material. Exposure is limited to applications that actually decrypt JWEs received from untrusted senders and do not reject compressed headers first; EPSS is 0.25% (16th percentile), no confirmed active exploitation (CISA KEV) is recorded, and a proof-of-concept script with supporting logs is published in the upstream advisory GHSA-wfpv-qxp8-x5gm.
Authentication-tag forgery in the Erlang JOSE library (jose 1.2.0 through 1.11.12) lets an unauthenticated remote attacker defeat AES-GCM integrity wherever decryption routes through the pure-Erlang jose_jwa_aes fallback - FIPS builds, or stripped or older OTP releases where :crypto does not expose a native AES-GCM NIF. Because verification compares only as many bits of the real 128-bit tag as the attacker-supplied tag contains, truncating the tag to a single byte drops forgery resistance to 2^-8, so a forged JWE with attacker-chosen ciphertext is accepted within 256 attempts without knowledge of the key; an over-length tag instead triggers a badmatch that crashes the decrypting process. A public PoC reference exists (advisory-attached Elixir script); it is not verified as working exploit code, there is no confirmed active exploitation (not in CISA KEV), and EPSS is 0.11% (2nd percentile), consistent with the conditional fallback prerequisite.
Credential leakage in Erlang hackney before 4.9.0 can expose HTTP basic_auth and cookie values when an application enables follow_redirect and a server returns a same-host redirect that changes scheme or port. The redirect handling compared only the hostname, so an https-to-http downgrade resent Authorization and Cookie headers in cleartext for an on-path attacker, while a same-host port change handed them to another service. The independent assessment rates this as medium severity (CVSS:3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N); no public exploit was identified at time of analysis.
Denial of service in Erlang OTP's stdlib erl_tar module (OTP 29.0 before 29.1.2, stdlib 8.0 before 8.1.1) allows an attacker who supplies a tar archive to be extracted to disk to hang the extracting process and consume a scheduler indefinitely, using a crafted GNU sparse member with a sparse map that ends before its declared real size. The same vulnerable code is vendored as hex_erl_tar in hex_core 0.14.0 and later, as mix_hex_erl_tar in Hex 2.4.2 and later, and as r3_hex_erl_tar in rebar3 3.27.1 and later, so those components remain exploitable on any OTP release including OTP 28. The assessed vector is local and unauthenticated (AV:L/AC:L/PR:N/UI:N) with availability-only impact on a single process/scheduler; no public exploit identified at time of analysis, and extraction using the memory output option is not affected.
TLS 1.2 session resumption in the Erlang/OTP ssl application can let a client holding a certificate trusted by one SNI virtual host authenticate to a second SNI virtual host served from the same listen socket, because the per-listener pre-TLS 1.3 session cache is not bound to the SNI name or the trust policy that established it. The flaw is exploitable only under a specific configuration: pre-TLS 1.3 negotiation, multiple SNI names sharing one server certificate (wildcard or multi-SAN), an SNI option set that switches to verify_peer without explicitly setting reuse_sessions, and an attacker who already possesses a client certificate trusted by at least one of the virtual hosts; TLS 1.3 is unaffected. CISA KEV does not list this issue and no public exploit code was identified at time of analysis, though EPSS-style urgency is low given a published vendor patch. The published CVSS 4.0 score is 6.3 (PR:N), while independent assessment rates it around CVSS 3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N - a genuine but conditional trust-confusion/authentication-bypass issue rather than a mass-exploitation priority.
Memory exhaustion in hex_core (a library vendored into Hex/mix and rebar3) lets an untrusted repository mirror or a malicious server answering hex_core API requests abort the client-side Erlang VM by returning a tiny, highly compressed response that expands into a very large term or signed envelope. The vulnerable code paths decompress and decode attacker-controlled bytes before the registry signature is verified, and the Erlang safe-binary decoder used for application/vnd.hex+erlang responses accepts compressed terms without bounding the decoded size. Exploitation requires the attacker to control the served data (malicious/compromised mirror, hostile API server, or TLS MITM) and the victim to actively run a fetch operation; this is an unauthenticated remote issue per the assessed vector (CVSS:4.0 PR:N, UI:A, AT:P), but it is a low-severity availability-only problem with no code execution or data exposure, and no public exploit identified at time of analysis.
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 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.
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 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.
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.
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.
Hostname verification in the Erlang library ssl_verify_fun (versions 1.0.1 through 1.1.7) mishandles partial-label wildcard certificate identifiers, letting a certificate such as f*.example.net be accepted for f.evil.example.net. A man-in-the-middle holding such a certificate from a CA the victim trusts could impersonate the peer, but only where ssl_verify_fun is the sole hostname check - clients with server_name_indication disabled, TLS servers using it to check client certificates, direct callers of verify_cert_hostname/2, or Erlang/OTP older than 20.0, since OTP 20.0+ with SNI set rejects the mismatch in ssl first. Fixed in 1.1.8; no public exploit identified at time of analysis, though a detailed proof-of-concept procedure is published in the advisory.
Password-protected private-key exports produced by the Erlang/Elixir `jose` library between 1.10.0 and 1.11.12 are encrypted with a hardcoded, drastically under-strength key-derivation step, so anyone who obtains such an exported blob can crack the export password offline at roughly 300 times less cost than modern guidance intends and recover the full private key. Only the password-based export path is affected (JOSE.JWK.to_der/2, jose_jwk:to_der/2, the PEM equivalents and their _file variants); the attack requires possession of the exported DER/PEM file and succeeds only where the export password is weak or moderate, since a long randomly generated password still resists 2048 PBKDF2 iterations. EPSS is very low (0.06%) and there is no KEV listing, but a public proof-of-concept script accompanies the upstream advisory; a public PoC reference exists and demonstrates parameter extraction plus dictionary recovery, though it is not verified here as working exploit code. The vendor fixed the parameters in 1.11.13, and the CVSS vector indicates no privileges are required (PR:N), with the practical gating factors being blob exposure and password strength rather than any network-reachable interface.
Memory exhaustion in the Erlang hackney HTTP client (2.0.0-beta.1 through 4.8.x) lets any server the client requests force the connection process to buffer an entire response body with no size bound; when {auto_decompress, true} is set, a small compressed body is additionally inflated in one zlib call, multiplying the allocation. The default hackney:request/5 and hackney:body/1 paths buffer the full body, so unauthenticated remote attackers who control or influence the target server (directly, via redirect, or via an SSRF-style URL) can crash or stall the calling BEAM process, giving availability-only impact. No public exploit code was identified at time of analysis and there is no KEV confirmation; 4.9.0 introduces a max_body_size option (default 512 MiB) that caps buffering and returns {error, body_too_large}.
Improper certificate validation in the Erlang HTTP client hackney (1.24.0 through 4.8.x) lets an on-path attacker impersonate a server that an application has pinned to a private certificate authority. Because hackney adds its own {partial_chain, fun hackney_ssl:partial_chain/1} to every verify_peer configuration and OTP honours that callback over a caller-supplied cacerts/cacertfile trust store, a chain ending in any certifi-bundled public root can be accepted as the trust anchor; the attacker still needs a man-in-the-middle position and a publicly trusted certificate for the exact pinned hostname that satisfies the hostname check, so only non-default private-CA pinning deployments are exposed. No public exploit identified at time of analysis and no CISA KEV entry, though the issue is triaged as act_now and fixed in hackney 4.9.0.
Unauthenticated remote attackers can crash an Erlang node running the Dropbox esaml SAML library (versions 0.1.0 and later) by sending a crafted SAMLResponse to the SAML assertion-consumer (ACS) or single-logout (SLO) endpoint. Because esaml_binding:decode_response/2 hands the decoded XML to xmerl_scan:string/2 before any signature check, every distinct element name, attribute name, and namespace prefix in the document is interned as a permanent Erlang atom; a few dozen requests carrying documents with thousands of unique names exhaust the roughly one-million-entry atom table and abort the VM. The CNA rates this CVSS 4.0 at 8.7, while independent assessment aligns with a CVSS:3.1 vector of AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H - pure availability impact with no confidentiality or integrity loss; no public exploit code was identified at time of analysis and there is no CISA KEV listing, though the flaw is trivially reachable by anyone who can POST to a SAML endpoint.
Unauthenticated remote denial of service in the Erlang SAML library esaml (0.1.0 and later) allows an attacker to abort an Erlang node by exhausting its atom table through unsigned LogoutResponse messages posted to a Service Provider's single-logout endpoint. Because esaml_sp:validate_logout_response/2 only verifies a signature when one is present, an unsigned message reaches esaml:decode_logout_response/1, where status_code_map/1 converts each unrecognized StatusCode into a permanent atom with list_to_atom/1 - roughly one million distinct status values (the VM's default atom-table ceiling) are enough to crash the node. The CNA scored this CVSS 4.0 8.2 with the AT:P attack-requirement metric; the practical barrier is volume and time rather than skill, and no public exploit code or confirmed active exploitation was identified at time of analysis.
Denial of service in the Erlang OTP ssl application allows a malicious or man-in-the-middle TLS 1.3 server to crash the node-global session-ticket store on a connecting client, and repeated crashes can exhaust the ssl supervisor restart intensity and take down TLS for every connection on that node. The victim must be a TLS 1.3 client running OTP 23.3 through the fixed releases with session_tickets set to auto (automatic ticket storage and resumption); the crash does not occur when the bogus ticket is received but on the next automatic resumption attempt, and it requires the client to initiate the outbound connection, which is reflected in the assessed AT:P attack-requirement metric and a CVSS 3.1 base of 5.9 (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) despite the vendor's CVSS 4.0 score of 8.2. No public exploit code has been identified at time of analysis and there is no CISA KEV listing, but vendor patches and upstream commits are available. Reported by the Erlang Ecosystem Foundation (EEF) and tracked as EUVD-2026-101384.
A path traversal flaw in rebar3, the standard build and dependency-management tool for Erlang/OTP, lets a malicious Hex package publisher cause rebar3 to delete an arbitrary directory and write package files into it whenever a developer or CI job fetches that package's dependencies. The attack abuses an unvalidated 'app' field in Hex registry dependency metadata: rebar3 treats that field as the dependency directory name, so a value such as '../../../../target' resolves outside the project's _build tree and is then removed with rm -rf before the fetched package is moved into place. Only rebar3 3.7.0-rc1 through 3.27.1 is affected, exploitation requires user interaction (a developer running rebar3 get-deps against a project that pulls in the malicious release, directly or transitively), and because the deletion occurs before the dependency's rebar.config.script is evaluated and get-deps compiles nothing, the practical impact is destructive file deletion and overwrite rather than immediate code execution; no public exploit code has been identified at time of analysis, and the public hex.pm registry added validation for the field on 2026-10-12, leaving private or self-hosted Hex registries as the main residual exposure.
Denial of service in the Erlang language bindings of Apache Thrift before 0.25.0 allows remote attackers to exhaust server resources through unbounded allocation, degrading or crashing the affected service. The flaw is CWE-770 (Allocation of Resources Without Limits or Throttling) and carries a CVSS v4.0 base score of 8.2; our independent assessment scores it CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H, reflecting a high-availability-only impact that requires a specific crafted message structure (AT:P) rather than arbitrary traffic. Only deployments running a Thrift server compiled with the Erlang bindings and exposed to attacker-reachable network traffic are affected; users of the C++, Java, Python, Go and other bindings are not impacted, and no public exploit code was identified at time of analysis.
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.
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.
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.
The RabbitMQ management plugin (rabbit_mgmt_cors.erl) reflects an attacker-controlled Origin header straight back in Access-Control-Allow-Origin while also returning Access-Control-Allow-Credentials: true, so when an operator has configured cors_allow_origins = "*" a hostile web page can make a signed-in administrator's browser issue authenticated, state-changing requests to the management HTTP API. Exploitation is conditional rather than automatic: it requires the non-default wildcard CORS setting, a live cached HTTP Basic-auth administrator session, and the administrator being lured to the attacker's page (user interaction), and no public exploit code has been identified at time of analysis; assessed severity is CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:H/I:H/A:N. The issue affects the management plugin in RabbitMQ releases prior to 3.13.17, 4.0.22, 4.1.13 and 4.2.6.
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.
Denial of service in Erlang/OTP's ASN.1 OBJECT IDENTIFIER decoders allows a remote, unauthenticated attacker to stall TLS-processing services by sending a crafted certificate during the handshake. Erlang/OTP releases from OTP 17.0 up to the fixed versions OTP 27.3.4.18, OTP 28.5.0.7 and OTP 29.1.1 are affected whenever the service parses a peer's X.509 certificate - the default for TLS clients (which always parse the server certificate) and for mutual-TLS servers - because the vulnerable BER OID decoder runs before signature and trust-chain verification, so an untrusted self-signed certificate is sufficient to trigger it. A single crafted OID with one very large arc (roughly 262 KB of continuation bytes) burns about 13 seconds of CPU, so sustained denial of service requires repeated connections; no public exploit code identified at time of analysis, and the impact is availability only (vendor CVSS 8.2; independently assessed as CVSS 3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H).
Authenticated remote attackers can exhaust node memory on Erlang/OTP SSH daemons by repeatedly opening "session" channels that never receive a shell, exec, or subsystem handler, eventually driving the BEAM emulator out of memory and terminating it - which kills every application sharing that node, not just the SSH service. The flaw (CWE-770) affects OTP 17.0 through 27.3.4.18, 28.5.0.7, and 29.1.1 (ssh 3.0.1 through 5.2.11.13, 5.5.2.6, and 6.0.6); an attacker must be able to complete SSH authentication first, but no user interaction, special configuration, or valid file/credential access is required, and CVSS scores it 7.1 (CVSS 4.0 availability-high, PR:L). No public exploit identified at time of analysis, and vendor-released patches are available. The documented max_channels daemon option does not mitigate the attack, so operators cannot rely on it as a stopgap.
Erlang/OTP's ssl application in affected releases (OTP 22.2 through the fixed 27.3.4.18, 28.5.0.7 and 29.1.1) will complete a TLS 1.3 client handshake against any peer that answers with an unsolicited pre_shared_key extension, allowing that peer to impersonate the intended server while holding no certificate, no private key and no prior session. Because the bogus resumption flag short-circuits certificate handling, ssl:connect returns {ok, Socket} even though certificate path validation, verify_fun, hostname verification, partial_chain, CRL checking and OCSP stapling are all skipped; an unauthenticated network-positioned attacker (man-in-the-middle, hijacked route/DNS, or a server the client is lured into contacting) can exploit this, and clients restricted to TLS 1.2 are not affected. A vendor patch is available and no public exploit code has been identified at time of analysis.
Authentication bypass in Erlang/OTP inets httpd allows remote unauthenticated attackers to read files inside mod_auth-protected directories across OTP 17.0 through 29.0 by prefixing the request URI with an extra slash. The inets URI normalizer preserves doubled slashes that RFC 3986 dot-segment removal does not collapse, causing mod_auth's directory-protection regex to silently fail to match while the OS transparently serves the protected file. No CISA KEV listing or public exploit code has been identified at time of analysis; CVSS 4.0 scores this 8.2 with high confidentiality impact contingent on mod_auth being explicitly configured.
Unauthenticated file disclosure in Erlang/OTP's inets httpd allows remote attackers on case-insensitive filesystem deployments to read files inside mod_auth-protected directories by requesting them with differently-cased path segments. The flaw spans OTP 17.0 through 29.x (inets 5.10 through 9.7.x) and stems from mod_auth's path-matching regex omitting the caseless flag, causing authentication checks to be silently bypassed when request path casing differs from the configured directory name while the filesystem resolves both to the same file. No public exploit code or active exploitation has been identified at time of analysis, and deployments on case-sensitive filesystems - the default on Linux - are fully unaffected by this vulnerability.
The BEAM runtime in Erlang/OTP crashes when a remote attacker sends a crafted packet to any exposed TCP port using the inet driver with {packet,4} framing, exploiting a signed integer overflow in packet length calculation inside packet_parser.c and inet_drv.c. Affected deployments span OTP release lines 17 through 29, with vendor-released patches available (27.3.4.17, 28.5.0.6, and 29.0.6); no active exploitation is confirmed in CISA KEV and no public exploit code has been identified at time of analysis. The vendor explicitly characterizes remote code execution as 'extremely unfeasible,' making denial-of-service via VM crash the realistic worst-case impact.
Erlang/OTP's inets HTTP server (httpd) fails to enforce an administrator-configured request body-size limit when processing chunked transfer-encoded requests, enabling unauthenticated remote attackers to exhaust server memory and cause denial of service. Affected OTP branches span 17.x through 27.3.4.16, 28.x through 28.5.0.5, and 29.x through 29.0.5, covering inets versions 5.10 through 9.7.1. No public exploit code has been identified and the CVE is not listed in the CISA KEV catalog, but the zero-authentication, low-complexity network attack path makes this an operationally straightforward DoS risk for any deployment exposing inets httpd to untrusted clients.
Request smuggling in Erlang OTP inets (versions 17.0 through 29.x) arises when the httpd server sits behind a Content-Length-preferring reverse proxy: inets frames the request body by chunked Transfer-Encoding and silently discards a co-present Content-Length header, while the front-end proxies request boundaries by Content-Length, producing a classic CL.TE desync. An unauthenticated network attacker in this topology can inject a crafted prefix into a subsequent victim's HTTP request, potentially enabling session hijacking, credential theft, or cache poisoning against other users of the same back-end. No public exploit has been identified at time of analysis, the vulnerability is not listed in CISA KEV, and vendor patches are available for the OTP 27.x, 28.x, and 29.x release branches.
Remote unauthenticated attackers can exploit Erlang/OTP's built-in inets HTTP server across OTP versions 22.2 through 29.0 to conduct HTTP Request Smuggling by sending headers with whitespace before the colon - a malformed construct the server silently discarded rather than rejecting as mandated by RFC 7230 Section 3.2.4. When inets is deployed behind a front-end proxy or load balancer that interprets such headers differently, the resulting parsing discordance creates a desynchronized request boundary exploitable for session hijacking, authentication bypass, or cache poisoning. No public exploit has been identified at time of analysis; vendor-released patches are available across all three affected OTP release branches.
HTTP request smuggling in Erlang/OTP's built-in inets httpd server allows unauthenticated remote attackers to inject arbitrary HTTP headers and poison request pipelines in deployments fronted by a reverse proxy. The root cause is a longstanding absence of obs-fold support: any CRLF followed by a whitespace octet (SP or TAB) is silently parsed as a new header rather than a header continuation, causing proxy-backend disagreement on request boundaries. Affected versions span OTP 17.0 through the patched releases (27.3.4.17, 28.5.0.6, 29.0.6), with vendor patches now available via the Erlang GitHub security advisory. No public exploit code or CISA KEV listing exists at time of analysis.
Unbounded memory exhaustion in the Erlang/OTP inets httpc HTTP client allows any server the client connects to - including via redirect or man-in-the-middle - to crash the BEAM VM by returning an arbitrarily large volume of response headers. The root cause is that max_header_size defaults to the atom nolimit and the header accumulation loop in httpc_response:parse_headers/6 collects all header data into an in-process list before any size check fires. A proof-of-concept server delivering 100,000 headers of ~4,000 bytes each consumed over 13 GB of RAM in under 30 seconds; no public exploit code has been separately released but the PoC is embedded in the official advisory, and vendor patches are available for OTP 27, 28, and 29 branches.
Erlang/OTP's inets HTTP server (httpd) is vulnerable to a slow-body resource exhaustion attack exploitable by unauthenticated remote attackers across OTP versions 17.0 through 29.0. The request handler cancels its active timeout after successfully parsing request headers, then re-arms the socket for body data without installing any replacement timer, allowing an attacker to open connections with syntactically valid headers and a large Content-Length and then stall indefinitely - permanently occupying a worker process per connection. Vendor patches are available for the OTP 27.x, 28.x, and 29.x branches; no public exploit code or CISA KEV listing has been identified at time of analysis.
Unauthenticated denial of service in Erlang/OTP's inets httpd allows any remote attacker to exhaust a server's process pool, memory, and file descriptors by holding open an unlimited number of TCP connections. The flaw affects all inets httpd deployments across OTP 17.x through 29.x that do not explicitly configure the max_clients option; when that option is absent, a type-comparison defect caused by Erlang's term-ordering rules makes the connection-count guard unconditionally pass, accepting connections without bound. Vendor patches are available in OTP 27.3.4.17, 28.5.0.6, and 29.0.6; no public exploit code or CISA KEV listing has been identified at time of analysis.
Denial of service in Erlang/OTP's TLS handshake allows remote unauthenticated attackers to crash the BEAM VM by sending a crafted X.509 certificate chain. The vulnerability affects OTP versions 26.2 through 29.0.3 and specific patch releases of 27 and 28, exploiting unbounded growth of the policy tree during path validation. No active exploitation or public exploit code is known at this time, but the attack is automatable and has a high CVSS score.
Erlang/OTP nodes that decode External Term Format (ETF) from untrusted sources can be aborted outright by a single malformed term, in versions from OTP 27.0 up to but not including the fixed releases OTP 29.0.4, 28.5.0.4 and 27.3.4.15 (erts 15.0 up to 17.0.4, 16.4.0.4 and 15.2.7.11). The BIT_BINARY_EXT tag (77) handler accepts an encoding with zero length and zero trailing bits, causing an unsigned underflow in the computed bitstring size; the resulting value near 2^64 is handed to the allocator, which terminates the entire VM with an abort rather than raising a catchable Erlang exception. The vulnerability is unauthenticated (CVSS 4.0 vector PR:N) but requires the target application to feed attacker-controlled bytes into binary_to_term/1,2 or enif_binary_to_term(), an application-design precondition reflected as AT:P in the vendor vector and assessed as AC:H in our CVSS 3.1 evaluation; impact is availability-only (C:N/I:N/A:H). There is no indication of active exploitation (not in CISA KEV; SSVC exploitation: none) and EPSS is low at 0.32% (24th percentile), and no public exploit code has been identified at time of analysis. Vendor-released patches are available.
Remote code execution and denial of service are possible against Erlang/OTP nodes that run the megaco application with the optional flex C-driver scanner, because a single text-encoded H.248/Megaco message carrying an oversized property parm name overflows a fixed 512-byte error buffer and corrupts live pointers inside the scanner driver struct. Affected are OTP releases from 17.0 up to the 29.0.4, 28.5.0.4 and 27.3.4.15 fixes (megaco 3.17.1 through 4.9.1, 4.8.3.1 and 4.7.2.2) where {scanner, flex} is configured; exploitation requires only network reachability to the megaco transport port, with no authentication or user interaction (vendor CVSS:4.0 8.3; independent assessment CVSS:3.1 AV:N/AC:H/PR:N/UI:N/C:N/I:L/A:H). Reliable code execution is not confirmed and depends on struct/heap-layout grooming, builds compiled with _FORTIFY_SOURCE abort with SIGABRT (denial of service only), no public exploit code was identified at time of analysis, EPSS is 0.73% (51st percentile), and CISA SSVC rates exploitation as none with automatable as no.
An on-path attacker can force an Erlang/OTP TLS 1.2 or DTLS client to accept an anonymous cipher suite not offered by the client, bypassing certificate validation and enabling full traffic decryption and manipulation. This affects OTP versions 17.0 through prior to 27.3.4.15, 28.5.0.4, and 29.0.4. The vulnerability is resolved in patched releases; no active exploitation or public proof-of-concept is known at this time.
Uncontrolled recursion in the Erlang/OTP ssl application when processing a crafted TLS/DTLS certificate chain allows remote attackers to exhaust memory and crash the BEAM node. Affects OTP versions 23.2 to before 27.3.4.15, 28.5.0.4, 29.0.4 (ssl 10.2 to before 11.2.12.11, 11.6.0.4, 11.7.4). No user interaction or authentication required, making this a pre-authentication denial-of-service risk for any TLS
Remote denial of service in Erlang/OTP's ssl application (dtls_packet_demux module) lets an unauthenticated attacker crash every active DTLS session on a listener by rapidly reconnecting from the same source IP and port. Because a single shared demux gen_server routes all UDP datagrams for a listener, its TOCTOU-induced crash takes down all clients, not just the attacker's, and can be repeated for a persistent outage. No public exploit is identified at time of analysis, and the issue is not listed in CISA KEV.
Denial of service in the Erlang/OTP ssl application (OTP 22.2 through 29.0.3, and the 28.5.x/27.3.x maintenance branches) lets an unauthenticated remote attacker permanently disable TLS 1.3 session ticket handling on a listener with a single crafted ClientHello. Because the pre-shared key extension's identity list and binder list are not length-checked before being handed to the session ticket handler, a mismatched OfferedPreSharedKeys record crashes that process, causing all subsequent TLS 1.3 handshakes to fail at ticket issuance until the ssl application is restarted. No public exploit identified at time of analysis and it is not on CISA KEV, but the CVSS 4.0 base score of 8.2 reflects the trivial, pre-authentication trigger.
Credential leakage in Erlang/OTP's inets httpc client (versions 17.0 through 29.0.2, 28.5.0.2, and 27.3.4.13) allows attacker-controlled servers to harvest Authorization and Proxy-Authorization headers by issuing cross-origin 3xx redirects. Because httpc_response:redirect/2 only updates the host field and copies all other headers verbatim - and autoredirect defaults to true - any httpc caller using HTTP Basic auth or URL userinfo silently forwards credentials to the redirect target. No public exploit identified at time of analysis, but the fix has been published upstream and tagged in vendor-released OTP patch versions.
Authentication bypass in Erlang/OTP's TLS distribution module (inet_tls_dist) lets any attacker holding a TLS certificate signed by a CA in the node's trust store gain full Erlang distribution access, including remote code execution via rpc:call/4 and code:load_binary/3. The flaw stems from check_ip/1 inspecting the local socket address (inet:sockname/1) instead of the peer's address (inet:peername/1), so the LAN-allowlist subnet comparison always matches. No public exploit identified at time of analysis, but the one-line root cause is fully disclosed in the upstream fix commit.
Denial of service in Erlang/OTP erts (inet_drv SCTP handler) lets unauthenticated remote attackers crash the BEAM VM by sending a single crafted SCTP ERROR chunk to a listening SCTP port. The flaw is a stack-based buffer overflow (CWE-121) in sctp_parse_error_chunk, with the publicly disclosed advisory from the Erlang Ecosystem Foundation (EEF) and an upstream commit confirming the fix; no public exploit identified at time of analysis, and the overflow only permits writing 16-bit values interleaved with a fixed tag, limiting impact to DoS plus minor memory disclosure.
TLS server impersonation in Erlang/OTP's public_key library lets a name-constrained subordinate CA forge a trusted identity for hostnames outside its permitted DNS subtree. By chaining a nameConstraints enforcement gap with a legacy CommonName fallback in pkix_verify_hostname/3, an attacker holding a DNS-restricted intermediate (e.g. permitted;DNS:allowed.example.com) can issue a SAN-less leaf whose CN is an out-of-scope host (e.g. victim.example.com) and have a stock ssl:connect client with verify_peer accept it. It affects OTP 19.3 through the fixed releases (public_key 1.4 onward) and is rated CVSS 4.0 7.6; there is no public exploit identified at time of analysis and it is not on CISA KEV.
Certificate chain forgery in Erlang/OTP's public_key application (pubkey_cert module) lets a non-CA end-entity certificate act as an intermediate issuer, allowing an attacker holding such a certificate's private key to sign forged leaf certificates for arbitrary identities that public_key:pkix_path_validation/3 will accept. This breaks server identity verification for TLS clients and client-certificate verification for mTLS servers across any application using the OTP ssl stack with the default verifier. Tracked as CWE-295 with a CVSS 4.0 base score of 7.0 (subsequent-system confidentiality and integrity rated High); no public exploit identified at time of analysis and it is not listed in CISA KEV, with the only available code being the vendor fix commits.
Authorization bypass in Erlang OTP's inets HTTP server allows unanauthenticated remote attackers to execute CGI scripts protected by directory-level access controls. The vulnerability stems from a path mismatch where mod_auth validates access against DocumentRoot-relative paths while mod_cgi executes scripts at ScriptAlias-resolved paths outside DocumentRoot. With CVSS 8.3 (AV:N/AC:L/PR:N), the attack requires no authentication and low complexity but depends on specific ScriptAlias configuration
Erlang OTP public_key module (versions 1.16 through 1.20.3 and 1.17.1.2) fails to cryptographically verify OCSP responder certificate signatures, allowing network attackers to forge OCSP responses with self-signed certificates bearing matching issuer names and OCSPSigning extended key usage. This bypasses certificate revocation checks in SSL/TLS clients using OCSP stapling, enabling man-in-the-middle attackers to present revoked certificates as valid and intercept sensitive communications. Vendo
A critical HTTP Request Smuggling vulnerability exists in Erlang OTP's inets httpd module that allows attackers to desynchronize front-end and back-end servers by exploiting inconsistent Content-Length header parsing. The vulnerability affects Erlang OTP versions from 17.0 through 28.4.0 (inets 5.10 through 9.6.0) and enables attackers to bypass security controls, potentially poisoning web caches or accessing unauthorized resources. While not currently listed in CISA KEV or showing high EPSS scores, the vulnerability has a CVSS 4.0 score of 7.0 and could lead to significant security boundary violations in production environments using affected Erlang-based web services.
Erlang/OTP SSH server allows unauthenticated remote code execution by exploiting a flaw in SSH protocol message handling, enabling unauthorized system access with CVSS 10.0.
ECDSA JWS signature malleability in erlang-jose (potatosalad:jose) 1.0.0 through 1.11.12 lets anyone holding a single legitimately issued ES256/ES256K/ES384/ES512 token produce multiple distinct signature byte strings that all verify against the same key, because verify/4 never checks the RFC 7518 §3.4 fixed signature length. It cannot forge new payloads or impersonate a signer - the underlying (r, s) pair is unchanged - but it defeats controls that assume a token or signature is unique, such as token-revocation-by-hash, replay/idempotency caches and deduplication keyed on raw signature bytes; applications that enforce uniqueness via a claim such as jti are not meaningfully affected. Exploitation requires an already-valid token as input (assessed vector AV:N/PR:L), a demonstration PoC reference ships with the vendor advisory but it is not verified as working exploit code against third-party deployments, EPSS is 0.09% (1st percentile), there is no CISA KEV listing, and the vendor released a fix in 1.11.13.
Memory-exhaustion denial of service in the erlang-jose JOSE/JWE library for Erlang and Elixir (versions 1.0.0 through 1.11.12) lets a remote, unauthenticated attacker inflate a few-kilobyte JWE token into hundreds of megabytes or gigabytes on the decrypting node and crash the BEAM. When a token carries the optional zip: "DEF" header, jose_jwe_zip:uncompress/2 feeds the entire attacker-controlled plaintext to zlib:inflate/2 with no output-size or inflation-ratio bound, and this happens automatically inside jose_jwe:block_decrypt/2 (JOSE.JWE.block_decrypt/2) before the recipient can inspect or reject the payload; with RSA-OAEP or ECDH-ES key management the attacker only needs the recipient's public key and no secret material. Exposure is limited to applications that actually decrypt JWEs received from untrusted senders and do not reject compressed headers first; EPSS is 0.25% (16th percentile), no confirmed active exploitation (CISA KEV) is recorded, and a proof-of-concept script with supporting logs is published in the upstream advisory GHSA-wfpv-qxp8-x5gm.
Authentication-tag forgery in the Erlang JOSE library (jose 1.2.0 through 1.11.12) lets an unauthenticated remote attacker defeat AES-GCM integrity wherever decryption routes through the pure-Erlang jose_jwa_aes fallback - FIPS builds, or stripped or older OTP releases where :crypto does not expose a native AES-GCM NIF. Because verification compares only as many bits of the real 128-bit tag as the attacker-supplied tag contains, truncating the tag to a single byte drops forgery resistance to 2^-8, so a forged JWE with attacker-chosen ciphertext is accepted within 256 attempts without knowledge of the key; an over-length tag instead triggers a badmatch that crashes the decrypting process. A public PoC reference exists (advisory-attached Elixir script); it is not verified as working exploit code, there is no confirmed active exploitation (not in CISA KEV), and EPSS is 0.11% (2nd percentile), consistent with the conditional fallback prerequisite.
Credential leakage in Erlang hackney before 4.9.0 can expose HTTP basic_auth and cookie values when an application enables follow_redirect and a server returns a same-host redirect that changes scheme or port. The redirect handling compared only the hostname, so an https-to-http downgrade resent Authorization and Cookie headers in cleartext for an on-path attacker, while a same-host port change handed them to another service. The independent assessment rates this as medium severity (CVSS:3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N); no public exploit was identified at time of analysis.
Denial of service in Erlang OTP's stdlib erl_tar module (OTP 29.0 before 29.1.2, stdlib 8.0 before 8.1.1) allows an attacker who supplies a tar archive to be extracted to disk to hang the extracting process and consume a scheduler indefinitely, using a crafted GNU sparse member with a sparse map that ends before its declared real size. The same vulnerable code is vendored as hex_erl_tar in hex_core 0.14.0 and later, as mix_hex_erl_tar in Hex 2.4.2 and later, and as r3_hex_erl_tar in rebar3 3.27.1 and later, so those components remain exploitable on any OTP release including OTP 28. The assessed vector is local and unauthenticated (AV:L/AC:L/PR:N/UI:N) with availability-only impact on a single process/scheduler; no public exploit identified at time of analysis, and extraction using the memory output option is not affected.
TLS 1.2 session resumption in the Erlang/OTP ssl application can let a client holding a certificate trusted by one SNI virtual host authenticate to a second SNI virtual host served from the same listen socket, because the per-listener pre-TLS 1.3 session cache is not bound to the SNI name or the trust policy that established it. The flaw is exploitable only under a specific configuration: pre-TLS 1.3 negotiation, multiple SNI names sharing one server certificate (wildcard or multi-SAN), an SNI option set that switches to verify_peer without explicitly setting reuse_sessions, and an attacker who already possesses a client certificate trusted by at least one of the virtual hosts; TLS 1.3 is unaffected. CISA KEV does not list this issue and no public exploit code was identified at time of analysis, though EPSS-style urgency is low given a published vendor patch. The published CVSS 4.0 score is 6.3 (PR:N), while independent assessment rates it around CVSS 3.1 AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:L/A:N - a genuine but conditional trust-confusion/authentication-bypass issue rather than a mass-exploitation priority.
Memory exhaustion in hex_core (a library vendored into Hex/mix and rebar3) lets an untrusted repository mirror or a malicious server answering hex_core API requests abort the client-side Erlang VM by returning a tiny, highly compressed response that expands into a very large term or signed envelope. The vulnerable code paths decompress and decode attacker-controlled bytes before the registry signature is verified, and the Erlang safe-binary decoder used for application/vnd.hex+erlang responses accepts compressed terms without bounding the decoded size. Exploitation requires the attacker to control the served data (malicious/compromised mirror, hostile API server, or TLS MITM) and the victim to actively run a fetch operation; this is an unauthenticated remote issue per the assessed vector (CVSS:4.0 PR:N, UI:A, AT:P), but it is a low-severity availability-only problem with no code execution or data exposure, and no public exploit identified at time of analysis.
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 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.
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 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.
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.
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.