{"id":"CVE-2026-67409","aliases":["AZL-109731","BIT-rabbitmq-2026-67409","DEBIAN-CVE-2026-67409","EUVD-2026-87159","GHSA-qw3h-qqm9-jrw8","OESA-2026-4028","OESA-2026-4030","OESA-2026-4031","OESA-2026-4032","RHSA-2026:67552","UBUNTU-CVE-2026-67409","USN-8933-1"],"status":"published","title":"RabbitMQ: JWKS Fetch Ignores HTTP Response Status Code - Signing Key Destruction Causes Authentication DoS","description":"RabbitMQ is a messaging and streaming broker. From 3.13.0 until 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18, JWKS Fetch Ignores HTTP Response Status Code - Signing Key Destruction Causes Authentication DoS (CWE-252). the JWKS key fetching mechanism in uaajwt.erl does not validate the HTTP response status code when downloading signing keys from the OAuth2 provider's JWKS endpoint. Non-200 responses (including 4xx and 5xx errors) are processed identically to successful responses. When the JWKS endpoint returns an error response with a valid-JSON body that lacks a keys field, all previously cached signing keys are destroyed, causing a persistent authentication denial of Files: deps/rabbitmqauthbackendoauth2/src/uaajwt.erl, lines 50-63 deps/rabbitmqauthbackendoauth2/src/uaajwks.erl, lines 5-7 deps/rabbitmqauthbackendoauth2/src/rabbitoauth2provider.erl, lines 98-107 Bug 1: HTTP status code ignored (uaajwt.erl:50-63): The Erlang httpc module returns {ok, {{HttpVersion, StatusCode, ReasonPhrase}, Headers, Body}}. The pattern {ok, {, , JwksBody}} matches ANY successful HTTP transaction Persistent authentication DoS: Once keys are destroyed, ALL OAuth2/JWT authentication fails for all users until a new successful JWKS refresh occurs Amplification: A single attacker can deny access to all legitimate OAuth2 users across the entire RabbitMQ. This issue is fixed in versions 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18.","severity":{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-10","score":0.00418,"percentile":0.36421,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-252"],"published":"2026-09-22T10:18:43Z","modified":"2026-11-06T14:16:53Z","fixes":[{"ecosystem":"Azure Linux:3","package":"rabbitmq-server","fixed_in":["3.13.7-11"],"sources":["osv"]},{"ecosystem":"Bitnami","package":"rabbitmq","fixed_in":["3.13.18","4.0.23","4.1.14","4.2.9","4.3.3"],"sources":["osv"]},{"ecosystem":"Debian:14","package":"rabbitmq-server","fixed_in":["4.3.6-1"],"sources":["osv"]},{"ecosystem":"Ubuntu:Pro:16.04:LTS","package":"rabbitmq-server","fixed_in":["3.5.7-1ubuntu0.16.04.4+esm3"],"sources":["osv"]},{"ecosystem":"Ubuntu:Pro:18.04:LTS","package":"rabbitmq-server","fixed_in":["3.6.10-1ubuntu0.5+esm1"],"sources":["osv"]},{"ecosystem":"Ubuntu:Pro:20.04:LTS","package":"rabbitmq-server","fixed_in":["3.8.3-0ubuntu0.3+esm2"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"rabbitmq-server","fixed_in":["3.9.27-0ubuntu0.6"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"rabbitmq-server","fixed_in":["3.12.1-1ubuntu1.7"],"sources":["osv"]},{"ecosystem":"Ubuntu:26.04:LTS","package":"rabbitmq-server","fixed_in":["4.0.5-10ubuntu5.2"],"sources":["osv"]}],"affected":[{"source":"osv","ecosystem":"Azure Linux:3","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.13.7-11"}]}]},{"source":"osv","ecosystem":"Bitnami","package":"rabbitmq","ranges":[{"type":"SEMVER","events":[{"introduced":"3.13.0"},{"fixed":"3.13.18"},{"introduced":"4.0.0"},{"fixed":"4.0.23"},{"introduced":"4.1.0"},{"fixed":"4.1.14"},{"introduced":"4.2.0"},{"fixed":"4.2.9"},{"introduced":"4.3.0"},{"fixed":"4.3.3"}]}]},{"source":"osv","ecosystem":"Debian:12","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["3.10.8-1.1","3.10.8-1.1+deb12u1","3.10.8-2","3.10.8-3","3.10.8-4","3.12.1-1","3.12.1-1.1","4.0.5-1","4.0.5-10","4.0.5-11","4.0.5-12","4.0.5-13","4.0.5-14","4.0.5-2","4.0.5-3","4.0.5-4","4.0.5-5","4.0.5-6","4.0.5-8","4.0.5-9","4.3.0-1","4.3.0-2","4.3.0-3","4.3.2-1","4.3.2-2","4.3.2-3","4.3.2-4","4.3.2-5","4.3.6-1"]},{"source":"osv","ecosystem":"Debian:13","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["4.0.5-10","4.0.5-11","4.0.5-12","4.0.5-13","4.0.5-14","4.0.5-6","4.0.5-6+deb13u1","4.0.5-6+deb13u2","4.0.5-8","4.0.5-9","4.3.0-1","4.3.0-2","4.3.0-3","4.3.2-1","4.3.2-2","4.3.2-3","4.3.2-4","4.3.2-5","4.3.6-1"]},{"source":"osv","ecosystem":"Debian:14","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.3.6-1"}]}],"versions":["4.0.5-10","4.0.5-11","4.0.5-12","4.0.5-13","4.0.5-14","4.0.5-6","4.0.5-8","4.0.5-9","4.3.0-1","4.3.0-2","4.3.0-3","4.3.2-1","4.3.2-2","4.3.2-3","4.3.2-4","4.3.2-5"]},{"source":"osv","ecosystem":"openEuler:24.03-LTS-SP4","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.9.23-4.oe2403sp4"}]}],"bundled":11},{"source":"osv","ecosystem":"openEuler:22.03-LTS-SP4","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.9.23-4.oe2203sp4"}]}],"bundled":11},{"source":"osv","ecosystem":"openEuler:24.03-LTS-SP1","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.9.23-4.oe2403sp1"}]}],"bundled":11},{"source":"osv","ecosystem":"openEuler:24.03-LTS-SP3","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.9.23-4.oe2403sp3"}]}],"bundled":11},{"source":"osv","ecosystem":"Red Hat:hummingbird:1","package":"rabbitmq-server4.3","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"0:4.3.6-1.hum1"}]}],"bundled":54},{"source":"osv","ecosystem":"Ubuntu:Pro:16.04:LTS","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.5.7-1ubuntu0.16.04.4+esm3"}]}],"versions":["3.5.4-1","3.5.4-3","3.5.4-3.1","3.5.7-1","3.5.7-1ubuntu0.16.04.1","3.5.7-1ubuntu0.16.04.2","3.5.7-1ubuntu0.16.04.4","3.5.7-1ubuntu0.16.04.4+esm1","3.5.7-1ubuntu0.16.04.4+esm2"]},{"source":"osv","ecosystem":"Ubuntu:Pro:18.04:LTS","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.6.10-1ubuntu0.5+esm1"}]}],"versions":["3.6.10-1","3.6.10-1ubuntu0.1","3.6.10-1ubuntu0.3","3.6.10-1ubuntu0.4","3.6.10-1ubuntu0.5"]},{"source":"osv","ecosystem":"Ubuntu:Pro:20.04:LTS","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.8.3-0ubuntu0.3+esm2"}]}],"versions":["3.7.8-4ubuntu2","3.7.18-1","3.8.2-0ubuntu1","3.8.2-0ubuntu1.1","3.8.2-0ubuntu1.2","3.8.2-0ubuntu1.3","3.8.2-0ubuntu1.4","3.8.2-0ubuntu1.5","3.8.3-0ubuntu0.1","3.8.3-0ubuntu0.2","3.8.3-0ubuntu0.3","3.8.3-0ubuntu0.3+esm1"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.9.27-0ubuntu0.6"}]}],"versions":["3.8.9-3ubuntu1","3.9.8-1","3.9.8-2","3.9.8-3","3.9.8-5","3.9.8-6","3.9.13-1","3.9.13-1ubuntu0.22.04.1","3.9.13-1ubuntu0.22.04.2","3.9.27-0ubuntu0.1","3.9.27-0ubuntu0.2","3.9.27-0ubuntu0.5"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.12.1-1ubuntu1.7"}]}],"versions":["3.12.1-1","3.12.1-1ubuntu1","3.12.1-1ubuntu1.2","3.12.1-1ubuntu1.4","3.12.1-1ubuntu1.6"]},{"source":"osv","ecosystem":"Ubuntu:26.10","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"}]}],"versions":["4.0.5-10ubuntu5","4.3.2-4ubuntu2","4.3.2-4ubuntu3"]},{"source":"osv","ecosystem":"Ubuntu:26.04:LTS","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.0.5-10ubuntu5.2"}]}],"versions":["4.0.5-8ubuntu2","4.0.5-10ubuntu1","4.0.5-10ubuntu2","4.0.5-10ubuntu3","4.0.5-10ubuntu4","4.0.5-10ubuntu5","4.0.5-10ubuntu5.1"]},{"source":"osv","ecosystem":"Ubuntu:Pro:16.04:LTS","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.5.7-1ubuntu0.16.04.4+esm3"}]}],"versions":["3.5.4-1","3.5.4-3","3.5.4-3.1","3.5.7-1","3.5.7-1ubuntu0.16.04.1","3.5.7-1ubuntu0.16.04.2","3.5.7-1ubuntu0.16.04.4","3.5.7-1ubuntu0.16.04.4+esm1","3.5.7-1ubuntu0.16.04.4+esm2"],"bundled":12},{"source":"osv","ecosystem":"Ubuntu:Pro:18.04:LTS","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.6.10-1ubuntu0.5+esm1"}]}],"versions":["3.6.10-1","3.6.10-1ubuntu0.1","3.6.10-1ubuntu0.3","3.6.10-1ubuntu0.4","3.6.10-1ubuntu0.5"],"bundled":12},{"source":"osv","ecosystem":"Ubuntu:Pro:20.04:LTS","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.8.3-0ubuntu0.3+esm2"}]}],"versions":["3.7.8-4ubuntu2","3.7.18-1","3.8.2-0ubuntu1","3.8.2-0ubuntu1.1","3.8.2-0ubuntu1.2","3.8.2-0ubuntu1.3","3.8.2-0ubuntu1.4","3.8.2-0ubuntu1.5","3.8.3-0ubuntu0.1","3.8.3-0ubuntu0.2","3.8.3-0ubuntu0.3","3.8.3-0ubuntu0.3+esm1"],"bundled":12},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.9.27-0ubuntu0.6"}]}],"versions":["3.8.9-3ubuntu1","3.9.8-1","3.9.8-2","3.9.8-3","3.9.8-5","3.9.8-6","3.9.13-1","3.9.13-1ubuntu0.22.04.1","3.9.13-1ubuntu0.22.04.2","3.9.27-0ubuntu0.1","3.9.27-0ubuntu0.2","3.9.27-0ubuntu0.5"],"bundled":12},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.12.1-1ubuntu1.7"}]}],"versions":["3.12.1-1","3.12.1-1ubuntu1","3.12.1-1ubuntu1.2","3.12.1-1ubuntu1.4","3.12.1-1ubuntu1.6"],"bundled":12},{"source":"osv","ecosystem":"Ubuntu:26.04:LTS","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.0.5-10ubuntu5.2"}]}],"versions":["4.0.5-8ubuntu2","4.0.5-10ubuntu1","4.0.5-10ubuntu2","4.0.5-10ubuntu3","4.0.5-10ubuntu4","4.0.5-10ubuntu5","4.0.5-10ubuntu5.1"],"bundled":12}],"products":[{"vendor":"broadcom","product":"rabbitmq_server"},{"vendor":"rabbitmq","product":"rabbitmq-server"}],"references":[{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-qw3h-qqm9-jrw8","tags":["x_refsource_CONFIRM","exploit","Exploit","Third Party Advisory","advisory","article","report"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/releases/tag/v4.2.9","tags":["x_refsource_MISC","Release Notes","article","web","report"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/releases/tag/v4.3.3","tags":["x_refsource_MISC","Release Notes","article","web","report"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67409","tags":["web","advisory"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/67xxx/CVE-2026-67409.json","tags":["advisory"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2026-67409","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4028","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2023-46118","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-30219","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-44839","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-57212","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-57213","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-57214","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-57215","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-57216","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-57221","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67413","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4030","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4031","tags":["advisory"]},{"url":"https://www.openeuler.org/zh/security/security-bulletins/detail/?id=openEuler-SA-2026-4032","tags":["advisory"]},{"url":"https://access.redhat.com/errata/RHSA-2026:67552","tags":["advisory"]},{"url":"https://images.redhat.com/","tags":["article"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-44839","tags":["report"]},{"url":"https://access.redhat.com/security/updates/classification/","tags":["article"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67221","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67219","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67224","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67232","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-66067","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-66077","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-66080","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67405","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67228","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67220","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67235","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-66074","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-66069","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-66075","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67240","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-66076","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-66070","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-66079","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67238","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-66072","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67218","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-66068","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67229","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67233","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67242","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67241","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-66071","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67227","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67234","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67226","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67406","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67409","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67415","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67408","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67239","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67223","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67410","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-66073","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67411","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67413","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67421","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67237","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67407","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-61837","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67419","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67420","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67222","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-66078","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67412","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67230","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67225","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67236","tags":["report"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-67404","tags":["report"]},{"url":"https://security.access.redhat.com/data/csaf/v2/advisories/2026/rhsa-2026_67552.json","tags":["advisory"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2482215","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-44839","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/7f54319279d1ece161ae0b4cdc6f0e58a4045eb5","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-fh5r-jpm3-fjwp","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2541517","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-61837","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-61837","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/341e3f2795ebd1f816e712530f651a3221d23ad9","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/b94004dea530f961b3dc649d94969b89f1a3183f","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-w9hf-476r-443x","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2539766","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-66067","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-66067","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/releases/tag/v4.2.7","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/releases/tag/v4.3.1","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-hwqx-2gfg-89qf","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2539769","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-66068","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-66068","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/releases/tag/v4.2.6","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/releases/tag/v4.3.0","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-9wm4-9m6g-w38x","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2539756","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-66069","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-66069","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-fhwq-9rvh-prj2","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2539724","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-66070","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-66070","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-p3hp-v9wh-ghm7","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2541515","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-66071","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-66071","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/9a44124d9c932d6fc7d2a3b945e5a143e547bcb6","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/c5690583a53789a3bf00cca508b43e8246db0d11","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-89p2-f5cv-x5cg","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2539758","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-66072","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-66072","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-48hm-chgv-398r","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2541508","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-66073","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-66073","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/7f64311471840e68f8cae09e4d4fdc4c8aca9229","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-6v53-r759-jrvx","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2539788","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-66074","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-66074","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-rg5q-vcgf-rfh7","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2539777","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-66075","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-66075","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-g5v3-w5xg-62q2","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2539721","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-66076","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-66076","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-j45q-v7g2-82ph","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2539765","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-66077","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-66077","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-rjcf-35r5-xw38","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2541499","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-66078","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-66078","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/e5b890a64b42ec1f79a8e9d735512150cf77479c","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-j9m2-hw6x-rqr9","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2539722","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-66079","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-66079","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-c66h-hf5j-8jf9","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2539757","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-66080","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-66080","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-wg79-5449-m728","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2539778","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67218","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67218","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-34jw-rm7g-hph4","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2539785","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67219","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67219","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-m8pg-4x2h-jvgr","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2539763","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67220","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67220","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-r3qr-4h63-mvj2","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2539794","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67221","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67221","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-x5h5-588r-cv55","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2541498","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67222","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67222","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-85jr-6rr2-j73r","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2541511","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67223","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67223","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/ad3ca47accd313a4a0dbcbbe17bf60fc8f4b2614","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/b54056e59b7fd3a2d7f07dfaba95f026e138eee8","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-9x7r-g78c-5835","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2539762","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67224","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67224","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-h7cq-qrr8-7vgc","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2541500","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67225","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67225","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-c8c4-gvv4-8j3q","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2541518","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67226","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67226","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/86601c5a6d1c7e41060e3dbd165c88bdc91266ee","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-34c7-r8w9-5wv8","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2541519","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67227","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67227","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/8fbe6d8112427e85fb9a9206b3eb6e9a3ddd3e39","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/fc591e7ee27a29657ca960930acefd3e4217e007","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-q7x8-97rh-cr24","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2539780","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67228","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67228","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-73qp-fwh4-2q5g","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2539770","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67229","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67229","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-ggrw-qm45-hwpv","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2541497","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67230","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67230","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/0b4080fa5d6f797b6331d0ce1db2b4bacd34560e","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/8138edae6d2beaafe699a41a754d17420bdc2068","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/c1000ba89052608c01c052d98016403ba6e92222","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-7v63-j4gm-p4rh","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2539787","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67232","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67232","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-gmgx-hhg5-43gr","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2540193","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67233","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67233","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-7jc3-73v6-rjvc","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2541504","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67234","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67234","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/149cb59d618cefa83c6deb02dbbb1e8a7a2bc968","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/baac0aaf170efeb4f124ee36b8417274fa8dcc1a","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/releases/tag/v4.2.8","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/releases/tag/v4.3.2","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-q286-p3m9-j69f","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2539784","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67235","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67235","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-q8g2-pc7m-m3jw","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2541491","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67236","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67236","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/df9e7f4c0afd311a672705f020d301efad355745","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/edf1fbc7217aaf736955d2e13c9534901a2e0778","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-88vh-gx85-p36m","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2541505","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67237","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67237","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/5cd6d841d84450324a4613501ed917d98828af23","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/a8041d528c1a71af4cb75ade247ed082fe6b83fb","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-2rf7-f6r6-8rwh","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2539723","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67238","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67238","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-x96j-244m-mrr2","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2541513","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67239","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67239","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-xm9p-57xv-vxwc","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2539764","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67240","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67240","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-59c5-553c-57m2","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2541502","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67241","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67241","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/18eac8d547b4382bf830c621b20a35932dd1cfa5","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/56005e7cebffc478ef397573de24aff1167e7cda","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-rg2g-289m-xhhw","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2541506","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67242","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67242","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/d10a369a96658d0fba1050bd43c732e58fcf28fd","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/f189a8824c9efbce46bd9438fcdbda4521cfc923","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-rrj4-g94f-rqj9","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2539759","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67404","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67404","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-37wx-r6q9-6fhj","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2539779","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67405","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67405","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-9c4f-rxxm-88q3","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2541521","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67406","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67406","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-q44f-9vc5-grh7","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2541524","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67407","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67407","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-q46v-hrvq-hp24","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2541516","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67408","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67408","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/0f3defd176e027f54f447beee168d906d4f109b6","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/eb11bc44005fd6d327a78bf171bc598207778c9b","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-2hm4-4438-49q8","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2541514","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67409","tags":["advisory","report"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2541522","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67410","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67410","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/60a85d3605ebf94fd234497242812547d441d457","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/869f800998334bb363f2ad046f58de9caedc409e","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-f9f2-q3jf-wfj3","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2541531","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67411","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67411","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/a7528314840c4f8dc9904684f9f97ffa7aac6349","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/edbead0eabbd65925d0dc914a22d6a29e155e646","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-4r6f-9cpw-f6g6","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2541507","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67412","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67412","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-42pc-678q-v8qj","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2541526","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67413","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/20203c50ea6ff459d462b2d4355326d3a870682c","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/60de2fbbcd812ab294985cef260cc2f1b1a02a5b","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/9e36b7f4c1e2eed77300288dca3e01bd9b23c432","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/f4d9da668b7304dfb9aeb2b4e9ff766a1275d021","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-chxf-3hfg-j8f7","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2541530","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67415","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67415","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-8mpg-qw9r-m5cr","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2541534","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67419","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67419","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/c5ed7c4e97e02be688730803604cc7a88dbe4864","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/releases/tag/v4.3.5","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-h964-v5mf-22cq","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2541535","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67420","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67420","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/5de287d213765ca592ff5848ad2f6b9b98ee6772","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-86fm-44m9-rqjx","tags":["article"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2541533","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2026-67421","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-67421","tags":["advisory"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/commit/ff595eaaa6d4f580f72fa04801ffd35f48c46027","tags":["article"]},{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-6256-27fm-4rgr","tags":["article"]},{"url":"https://ubuntu.com/security/CVE-2026-67409","tags":["report"]},{"url":"https://ubuntu.com/security/notices/USN-8933-1","tags":["advisory"]},{"url":"https://ubuntu.com/security/CVE-2026-66070","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-66077","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-66079","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-67231","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-67232","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-67235","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-67236","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-67237","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-67238","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-67239","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2026-67404","tags":["report"]}],"sources":{"cve":[{"id":"CVE-2026-67409","title":"RabbitMQ: JWKS Fetch Ignores HTTP Response Status Code - Signing Key Destruction Causes Authentication DoS","description":"RabbitMQ is a messaging and streaming broker. From 3.13.0 until 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18, JWKS Fetch Ignores HTTP Response Status Code - Signing Key Destruction Causes Authentication DoS (CWE-252). the JWKS key fetching mechanism in uaajwt.erl does not validate the HTTP response status code when downloading signing keys from the OAuth2 provider's JWKS endpoint. Non-200 responses (including 4xx and 5xx errors) are processed identically to successful responses. When the JWKS endpoint returns an error response with a valid-JSON body that lacks a keys field, all previously cached signing keys are destroyed, causing a persistent authentication denial of Files: deps/rabbitmqauthbackendoauth2/src/uaajwt.erl, lines 50-63 deps/rabbitmqauthbackendoauth2/src/uaajwks.erl, lines 5-7 deps/rabbitmqauthbackendoauth2/src/rabbitoauth2provider.erl, lines 98-107 Bug 1: HTTP status code ignored (uaajwt.erl:50-63): The Erlang httpc module returns {ok, {{HttpVersion, StatusCode, ReasonPhrase}, Headers, Body}}. The pattern {ok, {, , JwksBody}} matches ANY successful HTTP transaction Persistent authentication DoS: Once keys are destroyed, ALL OAuth2/JWT authentication fails for all users until a new successful JWKS refresh occurs Amplification: A single attacker can deny access to all legitimate OAuth2 users across the entire RabbitMQ. This issue is fixed in versions 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18.","status":"published","published":"2026-09-25T16:18:25.611Z","modified":"2026-09-25T17:49:48.064Z","cvss":[{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high","assessor":"cna"}],"cwes":["CWE-252"],"updated_at":"2026-11-02T14:20:06.562031Z"}],"euvd":[{"id":"EUVD-2026-87159","description":"RabbitMQ is a messaging and streaming broker. From 3.13.0 until 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18, JWKS Fetch Ignores HTTP Response Status Code - Signing Key Destruction Causes Authentication DoS (CWE-252). the JWKS key fetching mechanism in uaajwt.erl does not validate the HTTP response status code when downloading signing keys from the OAuth2 provider's JWKS endpoint. Non-200 responses (including 4xx and 5xx errors) are processed identically to successful responses. When the JWKS endpoint returns an error response with a valid-JSON body that lacks a keys field, all previously cached signing keys are destroyed, causing a persistent authentication denial of Files: deps/rabbitmqauthbackendoauth2/src/uaajwt.erl, lines 50-63 deps/rabbitmqauthbackendoauth2/src/uaajwks.erl, lines 5-7 deps/rabbitmqauthbackendoauth2/src/rabbitoauth2provider.erl, lines 98-107 Bug 1: HTTP status code ignored (uaajwt.erl:50-63): The Erlang httpc module returns {ok, {{HttpVersion, StatusCode, ReasonPhrase}, Headers, Body}}. The pattern {ok, {, , JwksBody}} matches ANY successful HTTP transaction Persistent authentication DoS: Once keys are destroyed, ALL OAuth2/JWT authentication fails for all users until a new successful JWKS refresh occurs Amplification: A single attacker can deny access to all legitimate OAuth2 users across the entire RabbitMQ. This issue is fixed in versions 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18.","status":"published","published":"2026-09-25T16:18:25Z","modified":"2026-09-25T17:49:48Z","cvss":[{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high"}],"updated_at":"2026-11-02T17:27:55.070935Z"}],"nvd":[{"id":"CVE-2026-67409","description":"RabbitMQ is a messaging and streaming broker. From 3.13.0 until 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18, JWKS Fetch Ignores HTTP Response Status Code - Signing Key Destruction Causes Authentication DoS (CWE-252). the JWKS key fetching mechanism in uaajwt.erl does not validate the HTTP response status code when downloading signing keys from the OAuth2 provider's JWKS endpoint. Non-200 responses (including 4xx and 5xx errors) are processed identically to successful responses. When the JWKS endpoint returns an error response with a valid-JSON body that lacks a keys field, all previously cached signing keys are destroyed, causing a persistent authentication denial of Files: deps/rabbitmqauthbackendoauth2/src/uaajwt.erl, lines 50-63 deps/rabbitmqauthbackendoauth2/src/uaajwks.erl, lines 5-7 deps/rabbitmqauthbackendoauth2/src/rabbitoauth2provider.erl, lines 98-107 Bug 1: HTTP status code ignored (uaajwt.erl:50-63): The Erlang httpc module returns {ok, {{HttpVersion, StatusCode, ReasonPhrase}, Headers, Body}}. The pattern {ok, {, , JwksBody}} matches ANY successful HTTP transaction Persistent authentication DoS: Once keys are destroyed, ALL OAuth2/JWT authentication fails for all users until a new successful JWKS refresh occurs Amplification: A single attacker can deny access to all legitimate OAuth2 users across the entire RabbitMQ. This issue is fixed in versions 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18.","status":"published","published":"2026-09-25T17:17:12.943Z","modified":"2026-10-08T15:36:44.86Z","cvss":[{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X","level":"high","assessor":"secondary"},{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium","assessor":"primary"}],"cwes":["CWE-252"],"updated_at":"2026-11-02T14:12:51.721923Z"}],"osv":[{"id":"CVE-2026-67409","title":"RabbitMQ: JWKS Fetch Ignores HTTP Response Status Code - Signing Key Destruction Causes Authentication DoS","description":"RabbitMQ is a messaging and streaming broker. From 3.13.0 until 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18, JWKS Fetch Ignores HTTP Response Status Code - Signing Key Destruction Causes Authentication DoS (CWE-252). the JWKS key fetching mechanism in uaajwt.erl does not validate the HTTP response status code when downloading signing keys from the OAuth2 provider's JWKS endpoint. Non-200 responses (including 4xx and 5xx errors) are processed identically to successful responses. When the JWKS endpoint returns an error response with a valid-JSON body that lacks a keys field, all previously cached signing keys are destroyed, causing a persistent authentication denial of Files: deps/rabbitmqauthbackendoauth2/src/uaajwt.erl, lines 50-63 deps/rabbitmqauthbackendoauth2/src/uaajwks.erl, lines 5-7 deps/rabbitmqauthbackendoauth2/src/rabbitoauth2provider.erl, lines 98-107 Bug 1: HTTP status code ignored (uaajwt.erl:50-63): The Erlang httpc module returns {ok, {{HttpVersion, StatusCode, ReasonPhrase}, Headers, Body}}. The pattern {ok, {, , JwksBody}} matches ANY successful HTTP transaction Persistent authentication DoS: Once keys are destroyed, ALL OAuth2/JWT authentication fails for all users until a new successful JWKS refresh occurs Amplification: A single attacker can deny access to all legitimate OAuth2 users across the entire RabbitMQ. This issue is fixed in versions 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18.","status":"published","published":"2026-09-25T16:18:25.611Z","modified":"2026-10-28T02:30:34.78202756Z","cvss":[{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high"}],"cwes":["CWE-252"],"updated_at":"2026-11-02T15:45:14.46177Z"},{"id":"DEBIAN-CVE-2026-67409","description":"RabbitMQ is a messaging and streaming broker. From 3.13.0 until 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18, JWKS Fetch Ignores HTTP Response Status Code - Signing Key Destruction Causes Authentication DoS (CWE-252). the JWKS key fetching mechanism in uaajwt.erl does not validate the HTTP response status code when downloading signing keys from the OAuth2 provider's JWKS endpoint. Non-200 responses (including 4xx and 5xx errors) are processed identically to successful responses. When the JWKS endpoint returns an error response with a valid-JSON body that lacks a keys field, all previously cached signing keys are destroyed, causing a persistent authentication denial of Files: deps/rabbitmqauthbackendoauth2/src/uaajwt.erl, lines 50-63 deps/rabbitmqauthbackendoauth2/src/uaajwks.erl, lines 5-7 deps/rabbitmqauthbackendoauth2/src/rabbitoauth2provider.erl, lines 98-107 Bug 1: HTTP status code ignored (uaajwt.erl:50-63): The Erlang httpc module returns {ok, {{HttpVersion, StatusCode, ReasonPhrase}, Headers, Body}}. The pattern {ok, {, , JwksBody}} matches ANY successful HTTP transaction Persistent authentication DoS: Once keys are destroyed, ALL OAuth2/JWT authentication fails for all users until a new successful JWKS refresh occurs Amplification: A single attacker can deny access to all legitimate OAuth2 users across the entire RabbitMQ. This issue is fixed in versions 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18.","status":"published","published":"2026-09-25T17:17:12.943Z","modified":"2026-10-10T22:00:16.275775983Z","cvss":[{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T15:46:01.68444Z"},{"id":"OESA-2026-4028","title":"rabbitmq-server security update","description":"RabbitMQ is an implementation of AMQP, the emerging standard for high performance enterprise messaging. The RabbitMQ server is a robust and scalable implementation of an AMQP broker.\r\n\r\nSecurity Fix(es):\n\nRabbitMQ is a multi-protocol messaging and streaming broker. HTTP API did not enforce an HTTP request body limit, making it vulnerable for denial of service (DoS) attacks with very large messages. An authenticated user with sufficient credentials can publish a very large messages over the HTTP API and cause target node to be terminated by an \u0026quot;out-of-memory killer\u0026quot;-like mechanism. This vulnerability has been patched in versions 3.11.24 and 3.12.7.(CVE-2023-46118)\n\nRabbitMQ is a messaging and streaming broker. Versions prior to 4.0.3 are vulnerable to a sophisticated attack that could modify virtual host name on disk and then make it unrecoverable (with other on disk file modifications) can lead to arbitrary JavaScript code execution in the browsers of management UI users. When a virtual host on a RabbitMQ node fails to start, recent versions\nwill display an error message (a notification) in the management UI. The error message includes virtual host name, which was not escaped prior to open source RabbitMQ 4.0.3 and Tanzu RabbitMQ 4.0.3, 3.13.8. An attack that both makes a virtual host fail to start and creates a new virtual host name with an XSS code snippet or changes the name of an existing virtual host on disk could trigger arbitrary JavaScript code execution in the management UI (the user\u0026apos;s browser). Open source RabbitMQ `4.0.3` and Tanzu RabbitMQ `4.0.3` and `3.13.8` patch the issue.(CVE-2025-30219)\n\nRabbitMQ is a messaging and streaming broker. From 3.7.0 to before 4.1.2 and 4.0.13,  This vulnerability is fixed in 4.1.2 and 4.0.13.(CVE-2026-44839)\n\nRabbitMQ is a messaging and streaming broker. Prior to 3.13.14, 4.0.19, 4.1.10, and 4.2.5, the rabbitmq_management HTTP API accepts oversized valid JSON bodies on with_decode and direct_request paths because read_complete_body checks the accumulated size before the final chunk but not the final combined size. This issue is fixed in versions 3.13.14, 4.0.19, 4.1.10, and 4.2.5.(CVE-2026-57212)\n\nRabbitMQ is a messaging and streaming broker. Prior to 3.13.14, 4.0.19, 4.1.10, and 4.2.5, the rabbitmq_federation_management plugin renders the consumer_tag field on the Federation Status page without HTML escaping, allowing a user who can configure a federation upstream or policy to execute JavaScript in the browser of a user viewing that page. This issue is fixed in versions 3.13.14, 4.0.19, 4.1.10, and 4.2.5.(CVE-2026-57213)\n\nRabbitMQ is a messaging and streaming broker. Prior to 4.2.5, the RabbitMQ management UI renders the x-internal-purpose queue or exchange argument into an HTML title attribute without proper escaping on the Queues and Exchanges pages, allowing a user with permission to declare a queue or exchange to execute JavaScript in another user\u0026apos;s browser. This issue is fixed in version 4.2.5.(CVE-2026-57214)\n\nRabbitMQ is a messaging and streaming broker. Prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6, RabbitMQ allows foreign bindings to amq.rabbitmq.reply-to destinations because volatile direct-reply-to queues can be accepted at bind and route time but are missing from Khepri-backed deletion checks, leaving persistent route entries after unbind. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.(CVE-2026-57215)\n\nRabbitMQ is a messaging and streaming broker. Prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6, AMQP 0-9-1, AMQP 1.0, and Stream Protocol authentication can allow a loopback-restricted user such as guest to connect remotely when traffic is accepted through a trusted PROXY-protocol path and the backend listener is loopback-bound because the loopback check uses the listener-side socket address instead of the real client source. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.(CVE-2026-57216)\n\nRabbitMQ is a messaging and streaming broker. Prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6, RabbitMQ does not perform authorization checks on passive queue.declare and exchange.declare AMQP 0-9-1 operations, allowing any authenticated user who can connect to a virtual host to enumerate queue and exchange names and read queue message and consumer counts. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.(CVE-2026-57221)\n\nAn authenticated tenant that is allowed to bind and publish to an `x-jms-topic` exchange can repeatedly consume RabbitMQ scheduler CPU while messages are routed. This delays publisher confirms and competes with unrelated broker work on the same node. The attacker can amplify the effect by publishing more messages or using multiple bindings, channels, or connections. The issue does not provide message disclosure, privilege escalation, or code execution. Its demonstrated impact is availability degradation. The reproduction establishes substantial per-message CPU amplification but does not claim that a single test connection alone causes a complete node outage.(CVE-2026-67409)\n\nAn authenticated tenant that is allowed to bind and publish to an `x-jms-topic` exchange can repeatedly consume RabbitMQ scheduler CPU while messages are routed. This delays publisher confirms and competes with unrelated broker work on the same node. The attacker can amplify the effect by publishing more messages or using multiple bindings, channels, or connections.\r\n\r\nThe issue does not provide message disclosure, privilege escalation, or code execution. Its demonstrated impact is availability degradation. The reproduction establishes substantial per-message CPU amplification but does not claim that a single test connection alone causes a complete node outage.(CVE-2026-67413)","status":"published","published":"2026-09-25T01:27:27Z","modified":"2026-09-25T01:45:06.393974498Z","cvss":[{"version":"3.1","score":8.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T15:52:47.643553Z"},{"id":"OESA-2026-4030","title":"rabbitmq-server security update","description":"RabbitMQ is an implementation of AMQP, the emerging standard for high performance enterprise messaging. The RabbitMQ server is a robust and scalable implementation of an AMQP broker.\r\n\r\nSecurity Fix(es):\n\nRabbitMQ is a multi-protocol messaging and streaming broker. HTTP API did not enforce an HTTP request body limit, making it vulnerable for denial of service (DoS) attacks with very large messages. An authenticated user with sufficient credentials can publish a very large messages over the HTTP API and cause target node to be terminated by an \u0026quot;out-of-memory killer\u0026quot;-like mechanism. This vulnerability has been patched in versions 3.11.24 and 3.12.7.(CVE-2023-46118)\n\nRabbitMQ is a messaging and streaming broker. Versions prior to 4.0.3 are vulnerable to a sophisticated attack that could modify virtual host name on disk and then make it unrecoverable (with other on disk file modifications) can lead to arbitrary JavaScript code execution in the browsers of management UI users. When a virtual host on a RabbitMQ node fails to start, recent versions\nwill display an error message (a notification) in the management UI. The error message includes virtual host name, which was not escaped prior to open source RabbitMQ 4.0.3 and Tanzu RabbitMQ 4.0.3, 3.13.8. An attack that both makes a virtual host fail to start and creates a new virtual host name with an XSS code snippet or changes the name of an existing virtual host on disk could trigger arbitrary JavaScript code execution in the management UI (the user\u0026apos;s browser). Open source RabbitMQ `4.0.3` and Tanzu RabbitMQ `4.0.3` and `3.13.8` patch the issue.(CVE-2025-30219)\n\nRabbitMQ is a messaging and streaming broker. From 3.7.0 to before 4.1.2 and 4.0.13,  This vulnerability is fixed in 4.1.2 and 4.0.13.(CVE-2026-44839)\n\nRabbitMQ is a messaging and streaming broker. Prior to 3.13.14, 4.0.19, 4.1.10, and 4.2.5, the rabbitmq_management HTTP API accepts oversized valid JSON bodies on with_decode and direct_request paths because read_complete_body checks the accumulated size before the final chunk but not the final combined size. This issue is fixed in versions 3.13.14, 4.0.19, 4.1.10, and 4.2.5.(CVE-2026-57212)\n\nRabbitMQ is a messaging and streaming broker. Prior to 3.13.14, 4.0.19, 4.1.10, and 4.2.5, the rabbitmq_federation_management plugin renders the consumer_tag field on the Federation Status page without HTML escaping, allowing a user who can configure a federation upstream or policy to execute JavaScript in the browser of a user viewing that page. This issue is fixed in versions 3.13.14, 4.0.19, 4.1.10, and 4.2.5.(CVE-2026-57213)\n\nRabbitMQ is a messaging and streaming broker. Prior to 4.2.5, the RabbitMQ management UI renders the x-internal-purpose queue or exchange argument into an HTML title attribute without proper escaping on the Queues and Exchanges pages, allowing a user with permission to declare a queue or exchange to execute JavaScript in another user\u0026apos;s browser. This issue is fixed in version 4.2.5.(CVE-2026-57214)\n\nRabbitMQ is a messaging and streaming broker. Prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6, RabbitMQ allows foreign bindings to amq.rabbitmq.reply-to destinations because volatile direct-reply-to queues can be accepted at bind and route time but are missing from Khepri-backed deletion checks, leaving persistent route entries after unbind. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.(CVE-2026-57215)\n\nRabbitMQ is a messaging and streaming broker. Prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6, AMQP 0-9-1, AMQP 1.0, and Stream Protocol authentication can allow a loopback-restricted user such as guest to connect remotely when traffic is accepted through a trusted PROXY-protocol path and the backend listener is loopback-bound because the loopback check uses the listener-side socket address instead of the real client source. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.(CVE-2026-57216)\n\nRabbitMQ is a messaging and streaming broker. Prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6, RabbitMQ does not perform authorization checks on passive queue.declare and exchange.declare AMQP 0-9-1 operations, allowing any authenticated user who can connect to a virtual host to enumerate queue and exchange names and read queue message and consumer counts. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.(CVE-2026-57221)\n\nAn authenticated tenant that is allowed to bind and publish to an `x-jms-topic` exchange can repeatedly consume RabbitMQ scheduler CPU while messages are routed. This delays publisher confirms and competes with unrelated broker work on the same node. The attacker can amplify the effect by publishing more messages or using multiple bindings, channels, or connections. The issue does not provide message disclosure, privilege escalation, or code execution. Its demonstrated impact is availability degradation. The reproduction establishes substantial per-message CPU amplification but does not claim that a single test connection alone causes a complete node outage.(CVE-2026-67409)\n\nAn authenticated tenant that is allowed to bind and publish to an `x-jms-topic` exchange can repeatedly consume RabbitMQ scheduler CPU while messages are routed. This delays publisher confirms and competes with unrelated broker work on the same node. The attacker can amplify the effect by publishing more messages or using multiple bindings, channels, or connections.\r\n\r\nThe issue does not provide message disclosure, privilege escalation, or code execution. Its demonstrated impact is availability degradation. The reproduction establishes substantial per-message CPU amplification but does not claim that a single test connection alone causes a complete node outage.(CVE-2026-67413)","status":"published","published":"2026-09-25T01:27:29Z","modified":"2026-09-25T01:45:06.498825644Z","cvss":[{"version":"3.1","score":8.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T15:52:47.643553Z"},{"id":"OESA-2026-4031","title":"rabbitmq-server security update","description":"RabbitMQ is an implementation of AMQP, the emerging standard for high performance enterprise messaging. The RabbitMQ server is a robust and scalable implementation of an AMQP broker.\r\n\r\nSecurity Fix(es):\n\nRabbitMQ is a multi-protocol messaging and streaming broker. HTTP API did not enforce an HTTP request body limit, making it vulnerable for denial of service (DoS) attacks with very large messages. An authenticated user with sufficient credentials can publish a very large messages over the HTTP API and cause target node to be terminated by an \u0026quot;out-of-memory killer\u0026quot;-like mechanism. This vulnerability has been patched in versions 3.11.24 and 3.12.7.(CVE-2023-46118)\n\nRabbitMQ is a messaging and streaming broker. Versions prior to 4.0.3 are vulnerable to a sophisticated attack that could modify virtual host name on disk and then make it unrecoverable (with other on disk file modifications) can lead to arbitrary JavaScript code execution in the browsers of management UI users. When a virtual host on a RabbitMQ node fails to start, recent versions\nwill display an error message (a notification) in the management UI. The error message includes virtual host name, which was not escaped prior to open source RabbitMQ 4.0.3 and Tanzu RabbitMQ 4.0.3, 3.13.8. An attack that both makes a virtual host fail to start and creates a new virtual host name with an XSS code snippet or changes the name of an existing virtual host on disk could trigger arbitrary JavaScript code execution in the management UI (the user\u0026apos;s browser). Open source RabbitMQ `4.0.3` and Tanzu RabbitMQ `4.0.3` and `3.13.8` patch the issue.(CVE-2025-30219)\n\nRabbitMQ is a messaging and streaming broker. From 3.7.0 to before 4.1.2 and 4.0.13,  This vulnerability is fixed in 4.1.2 and 4.0.13.(CVE-2026-44839)\n\nRabbitMQ is a messaging and streaming broker. Prior to 3.13.14, 4.0.19, 4.1.10, and 4.2.5, the rabbitmq_management HTTP API accepts oversized valid JSON bodies on with_decode and direct_request paths because read_complete_body checks the accumulated size before the final chunk but not the final combined size. This issue is fixed in versions 3.13.14, 4.0.19, 4.1.10, and 4.2.5.(CVE-2026-57212)\n\nRabbitMQ is a messaging and streaming broker. Prior to 3.13.14, 4.0.19, 4.1.10, and 4.2.5, the rabbitmq_federation_management plugin renders the consumer_tag field on the Federation Status page without HTML escaping, allowing a user who can configure a federation upstream or policy to execute JavaScript in the browser of a user viewing that page. This issue is fixed in versions 3.13.14, 4.0.19, 4.1.10, and 4.2.5.(CVE-2026-57213)\n\nRabbitMQ is a messaging and streaming broker. Prior to 4.2.5, the RabbitMQ management UI renders the x-internal-purpose queue or exchange argument into an HTML title attribute without proper escaping on the Queues and Exchanges pages, allowing a user with permission to declare a queue or exchange to execute JavaScript in another user\u0026apos;s browser. This issue is fixed in version 4.2.5.(CVE-2026-57214)\n\nRabbitMQ is a messaging and streaming broker. Prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6, RabbitMQ allows foreign bindings to amq.rabbitmq.reply-to destinations because volatile direct-reply-to queues can be accepted at bind and route time but are missing from Khepri-backed deletion checks, leaving persistent route entries after unbind. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.(CVE-2026-57215)\n\nRabbitMQ is a messaging and streaming broker. Prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6, AMQP 0-9-1, AMQP 1.0, and Stream Protocol authentication can allow a loopback-restricted user such as guest to connect remotely when traffic is accepted through a trusted PROXY-protocol path and the backend listener is loopback-bound because the loopback check uses the listener-side socket address instead of the real client source. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.(CVE-2026-57216)\n\nRabbitMQ is a messaging and streaming broker. Prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6, RabbitMQ does not perform authorization checks on passive queue.declare and exchange.declare AMQP 0-9-1 operations, allowing any authenticated user who can connect to a virtual host to enumerate queue and exchange names and read queue message and consumer counts. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.(CVE-2026-57221)\n\nAn authenticated tenant that is allowed to bind and publish to an `x-jms-topic` exchange can repeatedly consume RabbitMQ scheduler CPU while messages are routed. This delays publisher confirms and competes with unrelated broker work on the same node. The attacker can amplify the effect by publishing more messages or using multiple bindings, channels, or connections. The issue does not provide message disclosure, privilege escalation, or code execution. Its demonstrated impact is availability degradation. The reproduction establishes substantial per-message CPU amplification but does not claim that a single test connection alone causes a complete node outage.(CVE-2026-67409)\n\nAn authenticated tenant that is allowed to bind and publish to an `x-jms-topic` exchange can repeatedly consume RabbitMQ scheduler CPU while messages are routed. This delays publisher confirms and competes with unrelated broker work on the same node. The attacker can amplify the effect by publishing more messages or using multiple bindings, channels, or connections.\r\n\r\nThe issue does not provide message disclosure, privilege escalation, or code execution. Its demonstrated impact is availability degradation. The reproduction establishes substantial per-message CPU amplification but does not claim that a single test connection alone causes a complete node outage.(CVE-2026-67413)","status":"published","published":"2026-09-25T01:27:29Z","modified":"2026-09-25T01:45:06.600685393Z","cvss":[{"version":"3.1","score":8.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T15:52:47.643553Z"},{"id":"OESA-2026-4032","title":"rabbitmq-server security update","description":"RabbitMQ is an implementation of AMQP, the emerging standard for high performance enterprise messaging. The RabbitMQ server is a robust and scalable implementation of an AMQP broker.\r\n\r\nSecurity Fix(es):\n\nRabbitMQ is a multi-protocol messaging and streaming broker. HTTP API did not enforce an HTTP request body limit, making it vulnerable for denial of service (DoS) attacks with very large messages. An authenticated user with sufficient credentials can publish a very large messages over the HTTP API and cause target node to be terminated by an \u0026quot;out-of-memory killer\u0026quot;-like mechanism. This vulnerability has been patched in versions 3.11.24 and 3.12.7.(CVE-2023-46118)\n\nRabbitMQ is a messaging and streaming broker. Versions prior to 4.0.3 are vulnerable to a sophisticated attack that could modify virtual host name on disk and then make it unrecoverable (with other on disk file modifications) can lead to arbitrary JavaScript code execution in the browsers of management UI users. When a virtual host on a RabbitMQ node fails to start, recent versions\nwill display an error message (a notification) in the management UI. The error message includes virtual host name, which was not escaped prior to open source RabbitMQ 4.0.3 and Tanzu RabbitMQ 4.0.3, 3.13.8. An attack that both makes a virtual host fail to start and creates a new virtual host name with an XSS code snippet or changes the name of an existing virtual host on disk could trigger arbitrary JavaScript code execution in the management UI (the user\u0026apos;s browser). Open source RabbitMQ `4.0.3` and Tanzu RabbitMQ `4.0.3` and `3.13.8` patch the issue.(CVE-2025-30219)\n\nRabbitMQ is a messaging and streaming broker. From 3.7.0 to before 4.1.2 and 4.0.13,  This vulnerability is fixed in 4.1.2 and 4.0.13.(CVE-2026-44839)\n\nRabbitMQ is a messaging and streaming broker. Prior to 3.13.14, 4.0.19, 4.1.10, and 4.2.5, the rabbitmq_management HTTP API accepts oversized valid JSON bodies on with_decode and direct_request paths because read_complete_body checks the accumulated size before the final chunk but not the final combined size. This issue is fixed in versions 3.13.14, 4.0.19, 4.1.10, and 4.2.5.(CVE-2026-57212)\n\nRabbitMQ is a messaging and streaming broker. Prior to 3.13.14, 4.0.19, 4.1.10, and 4.2.5, the rabbitmq_federation_management plugin renders the consumer_tag field on the Federation Status page without HTML escaping, allowing a user who can configure a federation upstream or policy to execute JavaScript in the browser of a user viewing that page. This issue is fixed in versions 3.13.14, 4.0.19, 4.1.10, and 4.2.5.(CVE-2026-57213)\n\nRabbitMQ is a messaging and streaming broker. Prior to 4.2.5, the RabbitMQ management UI renders the x-internal-purpose queue or exchange argument into an HTML title attribute without proper escaping on the Queues and Exchanges pages, allowing a user with permission to declare a queue or exchange to execute JavaScript in another user\u0026apos;s browser. This issue is fixed in version 4.2.5.(CVE-2026-57214)\n\nRabbitMQ is a messaging and streaming broker. Prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6, RabbitMQ allows foreign bindings to amq.rabbitmq.reply-to destinations because volatile direct-reply-to queues can be accepted at bind and route time but are missing from Khepri-backed deletion checks, leaving persistent route entries after unbind. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.(CVE-2026-57215)\n\nRabbitMQ is a messaging and streaming broker. Prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6, AMQP 0-9-1, AMQP 1.0, and Stream Protocol authentication can allow a loopback-restricted user such as guest to connect remotely when traffic is accepted through a trusted PROXY-protocol path and the backend listener is loopback-bound because the loopback check uses the listener-side socket address instead of the real client source. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.(CVE-2026-57216)\n\nRabbitMQ is a messaging and streaming broker. Prior to 3.13.15, 4.0.20, 4.1.11, and 4.2.6, RabbitMQ does not perform authorization checks on passive queue.declare and exchange.declare AMQP 0-9-1 operations, allowing any authenticated user who can connect to a virtual host to enumerate queue and exchange names and read queue message and consumer counts. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, and 4.2.6.(CVE-2026-57221)\n\nAn authenticated tenant that is allowed to bind and publish to an `x-jms-topic` exchange can repeatedly consume RabbitMQ scheduler CPU while messages are routed. This delays publisher confirms and competes with unrelated broker work on the same node. The attacker can amplify the effect by publishing more messages or using multiple bindings, channels, or connections. The issue does not provide message disclosure, privilege escalation, or code execution. Its demonstrated impact is availability degradation. The reproduction establishes substantial per-message CPU amplification but does not claim that a single test connection alone causes a complete node outage.(CVE-2026-67409)\n\nAn authenticated tenant that is allowed to bind and publish to an `x-jms-topic` exchange can repeatedly consume RabbitMQ scheduler CPU while messages are routed. This delays publisher confirms and competes with unrelated broker work on the same node. The attacker can amplify the effect by publishing more messages or using multiple bindings, channels, or connections.\r\n\r\nThe issue does not provide message disclosure, privilege escalation, or code execution. Its demonstrated impact is availability degradation. The reproduction establishes substantial per-message CPU amplification but does not claim that a single test connection alone causes a complete node outage.(CVE-2026-67413)","status":"published","published":"2026-09-25T01:27:30Z","modified":"2026-09-25T01:45:06.995037851Z","cvss":[{"version":"3.1","score":8.8,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T15:52:47.643553Z"},{"id":"RHSA-2026:67552","title":"Red Hat Security Advisory: Red Hat Hardened Images RPMs bug fix and enhancement update","status":"published","published":"2026-09-22T10:18:43Z","modified":"2026-10-20T10:43:35.610185049Z","cvss":[{"version":"3.1","score":8.7,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:H/I:H/A:N","level":"high"}],"updated_at":"2026-11-02T15:53:22.406388Z"},{"id":"UBUNTU-CVE-2026-67409","description":"RabbitMQ is a messaging and streaming broker. From 3.13.0 until 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18, JWKS Fetch Ignores HTTP Response Status Code - Signing Key Destruction Causes Authentication DoS (CWE-252). the JWKS key fetching mechanism in uaajwt.erl does not validate the HTTP response status code when downloading signing keys from the OAuth2 provider's JWKS endpoint. Non-200 responses (including 4xx and 5xx errors) are processed identically to successful responses. When the JWKS endpoint returns an error response with a valid-JSON body that lacks a keys field, all previously cached signing keys are destroyed, causing a persistent authentication denial of Files: deps/rabbitmqauthbackendoauth2/src/uaajwt.erl, lines 50-63 deps/rabbitmqauthbackendoauth2/src/uaajwks.erl, lines 5-7 deps/rabbitmqauthbackendoauth2/src/rabbitoauth2provider.erl, lines 98-107 Bug 1: HTTP status code ignored (uaajwt.erl:50-63): The Erlang httpc module returns {ok, {{HttpVersion, StatusCode, ReasonPhrase}, Headers, Body}}. The pattern {ok, {, , JwksBody}} matches ANY successful HTTP transaction Persistent authentication DoS: Once keys are destroyed, ALL OAuth2/JWT authentication fails for all users until a new successful JWKS refresh occurs Amplification: A single attacker can deny access to all legitimate OAuth2 users across the entire RabbitMQ. This issue is fixed in versions 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18.","status":"published","published":"2026-09-25T17:17:00Z","modified":"2026-10-17T13:00:39.214643018Z","cvss":[{"version":"4.0","score":8.2,"vector":"CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N","level":"high"},{"version":"3.1","score":6.5,"vector":"CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:N/A:H","level":"medium"}],"updated_at":"2026-11-02T16:56:53.710209Z"},{"id":"AZL-109731","title":"CVE-2026-67409 affecting package rabbitmq-server for versions less than 3.13.7-11","description":"RabbitMQ is a messaging and streaming broker. From 3.13.0 until 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18, JWKS Fetch Ignores HTTP Response Status Code - Signing Key Destruction Causes Authentication DoS (CWE-252). the JWKS key fetching mechanism in uaajwt.erl does not validate the HTTP response status code when downloading signing keys from the OAuth2 provider's JWKS endpoint. Non-200 responses (including 4xx and 5xx errors) are processed identically to successful responses. When the JWKS endpoint returns an error response with a valid-JSON body that lacks a keys field, all previously cached signing keys are destroyed, causing a persistent authentication denial of Files: deps/rabbitmqauthbackendoauth2/src/uaajwt.erl, lines 50-63 deps/rabbitmqauthbackendoauth2/src/uaajwks.erl, lines 5-7 deps/rabbitmqauthbackendoauth2/src/rabbitoauth2provider.erl, lines 98-107 Bug 1: HTTP status code ignored (uaajwt.erl:50-63): The Erlang httpc module returns {ok, {{HttpVersion, StatusCode, ReasonPhrase}, Headers, Body}}. The pattern {ok, {, , JwksBody}} matches ANY successful HTTP transaction Persistent authentication DoS: Once keys are destroyed, ALL OAuth2/JWT authentication fails for all users until a new successful JWKS refresh occurs Amplification: A single attacker can deny access to all legitimate OAuth2 users across the entire RabbitMQ. This issue is fixed in versions 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18.","status":"published","published":"2026-09-25T17:17:12Z","modified":"2026-11-06T14:16:53.038419574Z","updated_at":"2026-11-06T14:57:15.495576Z"},{"id":"BIT-rabbitmq-2026-67409","title":"RabbitMQ: JWKS Fetch Ignores HTTP Response Status Code - Signing Key Destruction Causes Authentication DoS","description":"RabbitMQ is a messaging and streaming broker. From 3.13.0 until 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18, JWKS Fetch Ignores HTTP Response Status Code - Signing Key Destruction Causes Authentication DoS (CWE-252). the JWKS key fetching mechanism in uaajwt.erl does not validate the HTTP response status code when downloading signing keys from the OAuth2 provider's JWKS endpoint. Non-200 responses (including 4xx and 5xx errors) are processed identically to successful responses. When the JWKS endpoint returns an error response with a valid-JSON body that lacks a keys field, all previously cached signing keys are destroyed, causing a persistent authentication denial of Files: deps/rabbitmqauthbackendoauth2/src/uaajwt.erl, lines 50-63 deps/rabbitmqauthbackendoauth2/src/uaajwks.erl, lines 5-7 deps/rabbitmqauthbackendoauth2/src/rabbitoauth2provider.erl, lines 98-107 Bug 1: HTTP status code ignored (uaajwt.erl:50-63): The Erlang httpc module returns {ok, {{HttpVersion, StatusCode, ReasonPhrase}, Headers, Body}}. The pattern {ok, {, , JwksBody}} matches ANY successful HTTP transaction Persistent authentication DoS: Once keys are destroyed, ALL OAuth2/JWT authentication fails for all users until a new successful JWKS refresh occurs Amplification: A single attacker can deny access to all legitimate OAuth2 users across the entire RabbitMQ. This issue is fixed in versions 4.3.3, 4.2.9, 4.1.14, 4.0.23, and 3.13.18.","status":"published","published":"2026-10-01T09:33:49.456Z","modified":"2026-10-09T12:00:10.933131895Z","updated_at":"2026-11-02T15:28:35.111822Z"},{"id":"USN-8933-1","title":"rabbitmq-server vulnerabilities","description":"It was discovered that RabbitMQ Server incorrectly handled CORS wildcard\norigin configuration. An attacker could possibly use this issue to cause\na cross-site request forgery attack. This issue only affected Ubuntu 18.04\nLTS, Ubuntu 20.04 LTS, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and Ubuntu 26.04\nLTS. (CVE-2026-66070)\n\nIt was discovered that RabbitMQ Server incorrectly handled TLS\npeer-certificate DNs in the management UI. An attacker could possibly use\nthis issue to cause a cross-site scripting attack. (CVE-2026-66077)\n\nIt was discovered that RabbitMQ Server incorrectly handled AMQP 1.0 arrays\nwith zero-width element constructors. An attacker could possibly use this\nissue to cause a denial of service. This issue only affected Ubuntu 20.04\nLTS, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS.\n(CVE-2026-66079)\n\nIt was discovered that RabbitMQ Server trust-store plugin incorrectly\nvalidated client certificates. An attacker could possibly use this issue to\nbypass TLS client authentication. This issue only affected Ubuntu 18.04 LTS,\nUbuntu 20.04 LTS, Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS.\n(CVE-2026-67231)\n\nIt was discovered that RabbitMQ Server incorrectly handled WebSocket frame\nsizes. An attacker could possibly use this issue to cause a denial of\nservice. This issue only affected Ubuntu 20.04 LTS, Ubuntu 22.04 LTS,\nUbuntu 24.04 LTS, and Ubuntu 26.04 LTS. (CVE-2026-67232)\n\nIt was discovered that RabbitMQ Server incorrectly handled content-header\nbody sizes. An attacker could possibly use this issue to cause a denial of\nservice. (CVE-2026-67235)\n\nIt was discovered that RabbitMQ Server incorrectly stored credentials in an\ninsecure cookie. An attacker could possibly use this issue to expose\nsensitive information. This issue only affected Ubuntu 20.04 LTS, Ubuntu\n22.04 LTS, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS. (CVE-2026-67236)\n\nIt was discovered that RabbitMQ Server incorrectly handled OAuth bearer\ntokens in bootstrap JavaScript. An attacker could possibly use this issue\nto cause a cross-site scripting attack. This issue only affected Ubuntu\n24.04 LTS and Ubuntu 26.04 LTS. (CVE-2026-67237)\n\nIt was discovered that RabbitMQ Server incorrectly handled ETF-encoded PID\nnode names. An attacker could possibly use this issue to cause a denial of\nservice. This issue only affected Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and\nUbuntu 26.04 LTS. (CVE-2026-67238)\n\nIt was discovered that RabbitMQ Server incorrectly handled TLS\npeer-certificate DNs in the stream management UI. An attacker could\npossibly use this issue to cause a cross-site scripting attack. This issue\nonly affected Ubuntu 22.04 LTS, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS.\n(CVE-2026-67239)\n\nIt was discovered that RabbitMQ Server incorrectly handled OAuth2 SSL\noptions when no CA certificates were available. An attacker could possibly\nuse this issue to bypass TLS verification. This issue only affected Ubuntu\n26.04 LTS. (CVE-2026-67404)\n\nIt was discovered that RabbitMQ Server incorrectly validated HTTP response\nstatus codes when fetching JWKS keys. An attacker could possibly use this\nissue to cause a denial of service. This issue only affected Ubuntu 22.04\nLTS, Ubuntu 24.04 LTS, and Ubuntu 26.04 LTS. (CVE-2026-67409)","status":"published","published":"2026-10-15T17:27:24Z","modified":"2026-11-03T21:19:26.174439472Z","updated_at":"2026-11-03T21:43:32.336286Z"}]}}