{"id":"CVE-2025-30219","aliases":["AZL-59276","AZL-59281","BIT-rabbitmq-2025-30219","DEBIAN-CVE-2025-30219","EUVD-2025-8205","GHSA-g58g-82mw-9m3p","OESA-2026-4028","OESA-2026-4030","OESA-2026-4031","OESA-2026-4032","SUSE-SU-2025:01466-1","SUSE-SU-2025:01548-1","SUSE-SU-2025:1466-1","SUSE-SU-2025:1548-1","SUSE-SU-2026:20126-1","UBUNTU-CVE-2025-30219","USN-7399-1","openSUSE-SU-2025:15291-1","openSUSE-SU-2026:20082-1"],"status":"published","title":"RabbitMQ has XSS Vulnerability in an Error Message in Management UI","description":"RabbitMQ 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's browser). Open source RabbitMQ `4.0.3` and Tanzu RabbitMQ `4.0.3` and `3.13.8` patch the issue.","severity":{"version":"3.1","score":6.1,"vector":"CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:N/A:L","level":"medium","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00209,"percentile":0.11214,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-79"],"published":"2025-03-25T22:55:35Z","modified":"2026-11-05T05:40:51Z","fixes":[{"ecosystem":"Azure Linux:2","package":"rabbitmq-server","fixed_in":["3.11.24-3"],"sources":["osv"]},{"ecosystem":"Azure Linux:3","package":"rabbitmq-server","fixed_in":["3.13.7-2"],"sources":["osv"]},{"ecosystem":"Bitnami","package":"rabbitmq","fixed_in":["4.0.3"],"sources":["osv"]},{"ecosystem":"Debian:13","package":"rabbitmq-server","fixed_in":["4.0.5-1"],"sources":["osv"]},{"ecosystem":"Debian:14","package":"rabbitmq-server","fixed_in":["4.0.5-1"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Module for Server Applications 15 SP7","package":"rabbitmq-server","fixed_in":["3.8.11-150300.3.19.1"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Module for Server Applications 15 SP7","package":"rabbitmq-server313","fixed_in":["3.13.1-150600.13.8.1"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Module for Server Applications 15 SP6","package":"rabbitmq-server","fixed_in":["3.8.11-150300.3.19.1"],"sources":["osv"]},{"ecosystem":"openSUSE:Leap 15.6","package":"rabbitmq-server","fixed_in":["3.8.11-150300.3.19.1"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Module for Server Applications 15 SP6","package":"rabbitmq-server313","fixed_in":["3.13.1-150600.13.8.1"],"sources":["osv"]},{"ecosystem":"openSUSE:Leap 15.6","package":"rabbitmq-server313","fixed_in":["3.13.1-150600.13.8.1"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Server 16.0","package":"rabbitmq-server","fixed_in":["4.1.5-160000.1.1"],"sources":["osv"]},{"ecosystem":"SUSE:Linux Enterprise Server for SAP applications 16.0","package":"rabbitmq-server","fixed_in":["4.1.5-160000.1.1"],"sources":["osv"]},{"ecosystem":"Ubuntu:20.04:LTS","package":"rabbitmq-server","fixed_in":["3.8.3-0ubuntu0.3"],"sources":["osv"]},{"ecosystem":"Ubuntu:22.04:LTS","package":"rabbitmq-server","fixed_in":["3.9.27-0ubuntu0.2"],"sources":["osv"]},{"ecosystem":"Ubuntu:24.04:LTS","package":"rabbitmq-server","fixed_in":["3.12.1-1ubuntu1.2"],"sources":["osv"]},{"ecosystem":"openSUSE:Tumbleweed","package":"rabbitmq-server","fixed_in":["3.13.7-4.1"],"sources":["osv"]},{"ecosystem":"openSUSE:Leap 16.0","package":"rabbitmq-server","fixed_in":["4.1.5-160000.1.1"],"sources":["osv"]}],"affected":[{"source":"osv","ecosystem":"Azure Linux:2","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.11.24-3"}]}]},{"source":"osv","ecosystem":"Azure Linux:3","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.13.7-2"}]}]},{"source":"osv","ecosystem":"Bitnami","package":"rabbitmq","ranges":[{"type":"SEMVER","events":[{"introduced":"0"},{"fixed":"4.0.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"]},{"source":"osv","ecosystem":"Debian:13","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.0.5-1"}]}]},{"source":"osv","ecosystem":"Debian:14","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.0.5-1"}]}]},{"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":"SUSE:Linux Enterprise Module for Server Applications 15 SP7","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.8.11-150300.3.19.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Server Applications 15 SP7","package":"rabbitmq-server313","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.13.1-150600.13.8.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Server Applications 15 SP6","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.8.11-150300.3.19.1"}]}]},{"source":"osv","ecosystem":"openSUSE:Leap 15.6","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.8.11-150300.3.19.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Module for Server Applications 15 SP6","package":"rabbitmq-server313","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.13.1-150600.13.8.1"}]}]},{"source":"osv","ecosystem":"openSUSE:Leap 15.6","package":"rabbitmq-server313","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.13.1-150600.13.8.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server 16.0","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.1.5-160000.1.1"}]}]},{"source":"osv","ecosystem":"SUSE:Linux Enterprise Server for SAP applications 16.0","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.1.5-160000.1.1"}]}]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.8.3-0ubuntu0.3"}]}],"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"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.9.27-0ubuntu0.2"}]}],"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"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.12.1-1ubuntu1.2"}]}],"versions":["3.12.1-1","3.12.1-1ubuntu1"]},{"source":"osv","ecosystem":"Ubuntu:20.04:LTS","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.8.3-0ubuntu0.3"}]}],"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"]},{"source":"osv","ecosystem":"Ubuntu:22.04:LTS","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.9.27-0ubuntu0.2"}]}],"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"]},{"source":"osv","ecosystem":"Ubuntu:24.04:LTS","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.12.1-1ubuntu1.2"}]}],"versions":["3.12.1-1","3.12.1-1ubuntu1"]},{"source":"osv","ecosystem":"openSUSE:Tumbleweed","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"3.13.7-4.1"}]}]},{"source":"osv","ecosystem":"openSUSE:Leap 16.0","package":"rabbitmq-server","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"4.1.5-160000.1.1"}]}]}],"products":[{"vendor":"rabbitmq","product":"rabbitmq-server"}],"references":[{"url":"https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-g58g-82mw-9m3p","tags":["x_refsource_CONFIRM","web","advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2025-30219","tags":["web","advisory"]},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2025/30xxx/CVE-2025-30219.json","tags":["advisory"]},{"url":"https://security-tracker.debian.org/tracker/CVE-2025-30219","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-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-67409","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://www.suse.com/support/update/announcement/2025/suse-su-202501466-1/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1240071","tags":["report"]},{"url":"https://www.suse.com/security/cve/CVE-2025-30219","tags":["web"]},{"url":"https://www.suse.com/support/update/announcement/2025/suse-su-202501548-1/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1231656","tags":["report"]},{"url":"https://bugzilla.suse.com/1234763","tags":["report"]},{"url":"https://www.suse.com/support/update/announcement/2025/suse-su-20251466-1/","tags":["advisory"]},{"url":"https://www.suse.com/support/update/announcement/2025/suse-su-20251548-1/","tags":["advisory"]},{"url":"https://www.suse.com/support/update/announcement/2026/suse-su-202620126-1/","tags":["advisory"]},{"url":"https://bugzilla.suse.com/1246091","tags":["report"]},{"url":"https://ubuntu.com/security/CVE-2025-30219","tags":["report"]},{"url":"https://www.cve.org/CVERecord?id=CVE-2025-30219","tags":["report"]},{"url":"https://ubuntu.com/security/notices/USN-7399-1","tags":["advisory"]},{"url":"","tags":["advisory"]}],"sources":{"cve":[{"id":"CVE-2025-30219","title":"RabbitMQ has XSS Vulnerability in an Error Message in Management UI","description":"RabbitMQ 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's browser). Open source RabbitMQ `4.0.3` and Tanzu RabbitMQ `4.0.3` and `3.13.8` patch the issue.","status":"published","published":"2025-03-25T22:55:35.539Z","modified":"2025-03-26T13:43:18.25Z","cvss":[{"version":"3.1","score":6.1,"vector":"CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:N/A:L","level":"medium","assessor":"cna"}],"cwes":["CWE-79"],"updated_at":"2026-11-02T14:32:35.418416Z"}],"euvd":[{"id":"EUVD-2025-8205","description":"RabbitMQ 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's browser). Open source RabbitMQ `4.0.3` and Tanzu RabbitMQ `4.0.3` and `3.13.8` patch the issue.","status":"published","published":"2025-03-25T22:55:35Z","modified":"2025-03-26T13:43:18Z","cvss":[{"version":"3.1","score":6.1,"vector":"CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:N/A:L","level":"medium"}],"updated_at":"2026-11-02T20:52:51.751114Z"}],"nvd":[{"id":"CVE-2025-30219","description":"RabbitMQ 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's browser). Open source RabbitMQ `4.0.3` and Tanzu RabbitMQ `4.0.3` and `3.13.8` patch the issue.","status":"published","published":"2025-03-25T23:15:36.56Z","modified":"2026-06-17T09:08:22.773Z","cvss":[{"version":"3.1","score":6.1,"vector":"CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:N/A:L","level":"medium","assessor":"secondary"}],"cwes":["CWE-79"],"updated_at":"2026-11-02T14:10:55.858901Z"}],"osv":[{"id":"CVE-2025-30219","title":"RabbitMQ has XSS Vulnerability in an Error Message in Management UI","description":"RabbitMQ 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's browser). Open source RabbitMQ `4.0.3` and Tanzu RabbitMQ `4.0.3` and `3.13.8` patch the issue.","status":"published","published":"2025-03-25T22:55:35.539Z","modified":"2026-10-28T02:30:39.118547751Z","cvss":[{"version":"3.1","score":6.1,"vector":"CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:N/A:L","level":"medium"}],"cwes":["CWE-79"],"updated_at":"2026-11-02T15:44:47.708311Z"},{"id":"DEBIAN-CVE-2025-30219","description":"RabbitMQ 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 will 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's browser). Open source RabbitMQ `4.0.3` and Tanzu RabbitMQ `4.0.3` and `3.13.8` patch the issue.","status":"published","published":"2025-03-25T23:15:36.56Z","modified":"2026-09-01T20:05:45.546351342Z","cvss":[{"version":"3.1","score":6.1,"vector":"CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:N/A:L","level":"medium"}],"updated_at":"2026-11-02T15:45:45.870237Z"},{"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":"UBUNTU-CVE-2025-30219","description":"RabbitMQ 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 will 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's browser). Open source RabbitMQ `4.0.3` and Tanzu RabbitMQ `4.0.3` and `3.13.8` patch the issue.","status":"published","published":"2025-03-25T23:15:00Z","modified":"2026-02-04T02:13:42.118658Z","cvss":[{"version":"3.1","score":6.1,"vector":"CVSS:3.1/AV:L/AC:H/PR:H/UI:N/S:C/C:H/I:N/A:L","level":"medium"}],"updated_at":"2026-11-02T16:55:26.330196Z"},{"id":"AZL-59276","title":"CVE-2025-30219 affecting package rabbitmq-server for versions less than 3.11.24-3","description":"RabbitMQ 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's browser). Open source RabbitMQ `4.0.3` and Tanzu RabbitMQ `4.0.3` and `3.13.8` patch the issue.","status":"published","published":"2025-03-25T23:15:36Z","modified":"2026-04-21T04:37:14.743853Z","updated_at":"2026-11-02T15:28:07.517393Z"},{"id":"AZL-59281","title":"CVE-2025-30219 affecting package rabbitmq-server for versions less than 3.13.7-2","description":"RabbitMQ 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's browser). Open source RabbitMQ `4.0.3` and Tanzu RabbitMQ `4.0.3` and `3.13.8` patch the issue.","status":"published","published":"2025-03-25T23:15:36Z","modified":"2026-11-05T05:40:51Z","updated_at":"2026-11-05T16:41:21.344052Z"},{"id":"BIT-rabbitmq-2025-30219","title":"RabbitMQ has XSS Vulnerability in an Error Message in Management UI","description":"RabbitMQ 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's browser). Open source RabbitMQ `4.0.3` and Tanzu RabbitMQ `4.0.3` and `3.13.8` patch the issue.","status":"published","published":"2025-03-27T07:51:20.693Z","modified":"2025-10-15T22:57:36.465655Z","updated_at":"2026-11-02T15:28:35.111822Z"},{"id":"openSUSE-SU-2025:15291-1","title":"erlang-rabbitmq-client-3.13.7-4.1 on GA media","description":"These are all security issues fixed in the erlang-rabbitmq-client-3.13.7-4.1 package on the GA media of openSUSE Tumbleweed.","status":"published","published":"2025-07-03T00:00:00Z","modified":"2026-03-23T04:53:36.302816Z","updated_at":"2026-11-02T16:58:37.810934Z"},{"id":"openSUSE-SU-2026:20082-1","title":"Security update for rabbitmq-server","description":"This update for rabbitmq-server fixes the following issues:\n\nChanges in rabbitmq-server:\n\nUpdate to 4.1.5:\n\n* Highlights\n\n  - Khepri, an alternative schema data store developed to replace Mnesia,\n    has matured and is now fully supported (it previously was an experimental feature)\n  - AMQP 1.0 is now a core protocol that is always enabled. Its plugin is now a no-op that only exists to simplify upgrades.\n  - The AMQP 1.0 implementation is now significantly more efficient: its peak throughput is more than double than that of 3.13.x\n    on some workloads\n  - Efficient sub-linear quorum queue recovery on node startup using checkpoints\n  - Quorum queues now support priorities (but not exactly the same way as classic queues)\n  - AMQP 1.0 clients now can manage topologies similarly to how AMQP 0-9-1 clients do it\n  - The AMQP 1.0 convention (address format) used for interacting with with AMQP 0-9-1 entities is now easier to reason about\n  - Mirroring (replication) of classic queues was removed after several years of deprecation. For replicated messaging data types,\n    use quorum queues and/or streams. Non-replicated classic queues remain and their development continues\n  - Classic queue storage efficiency improvements, in particular recovery time and storage of multi-MiB messages\n  - Nodes with multiple enabled plugins and little on disk data to recover now start up to 20-30% faster\n  - New exchange type: Local Random Exchange\n  - Quorum queue log reads are now offloaded to channels (sessions, connections).\n  - Initial Support for AMQP 1.0 Filter Expressions\n  - Feature Flags Quality of Life Improvements\n  - rabbitmqadmin v2\n\n* Breaking Changes\n\n  - Before a client connection can negotiate a maximum frame size (frame_max), it must authenticate\n    successfully. Before the authenticated phase, a special lower frame_max value\n    is used.\n  - With this release, the value was increased from the original 4096 bytes to 8192\n    to accommodate larger JWT tokens.\n  - amqplib is a popular client library that has been using\n    a low frame_max default of 4096. Its users must upgrade to a compatible version\n    (starting with 0.10.7) or explicitly use a higher frame_max.\n    amqplib versions older than 0.10.7 will not be able to connect to\n    RabbitMQ 4.1.0 and later versions due to the initial AMQP 0-9-1 maximum frame size\n    increase covered above.\n  - The default MQTT Maximum Packet Size changed from 256 MiB to 16 MiB.\n  - The following rabbitmq.conf settings are unsupported:\n\n    - cluster_formation.etcd.ssl_options.fail_if_no_peer_cert\n    - cluster_formation.etcd.ssl_options.dh\n    - cluster_formation.etcd.ssl_options.dhfile\n\n  - Classic Queues is Now a Non-Replicated Queue Type\n  - Quorum Queues Now Have a Default Redelivery Limit\n  - Up to RabbitMQ 3.13, when an AMQP 0.9.1 client (re-)published a message to RabbitMQ, RabbitMQ interpreted the\n  - AMQP 0.9.1 x-death header in the published message's basic_message.content.properties.headers field.\n  - RabbitMQ 4.x will not interpret this x-death header anymore when clients (re-)publish a message.\n  - CQv1 Storage Implementation was Removed\n  - Settings cluster_formation.randomized_startup_delay_range.* were Removed\n  - Several Disk I/O-Related Metrics were Removed\n  - Default Maximum Message Size Reduced to 16 MiB\n  - RabbitMQ 3.13 rabbitmq.conf setting rabbitmq_amqp1_0.default_vhost is unsupported in RabbitMQ 4.0.\n  - RabbitMQ 3.13 rabbitmq.conf settings mqtt.default_user, mqtt.default_password,\n    and amqp1_0.default_user are unsupported in RabbitMQ 4.0.\n  - Starting with Erlang 26, client side TLS peer certificate chain verification settings are enabled by default in most contexts:\n    from federation links to shovels to TLS-enabled LDAP client connections.\n  - RabbitMQ Shovels will be able connect to a RabbitMQ 4.0 node via AMQP 1.0 only when the Shovel runs on a RabbitMQ node \u003e= 3.13.7.\n\n    * See https://github.com/rabbitmq/rabbitmq-server/releases/tag/v4.0.1\n    * and https://github.com/rabbitmq/rabbitmq-server/releases/tag/v4.1.0 for more info\n\n- Restore SLES logrotate file, (bsc#1246091)\n","status":"published","published":"2026-01-22T13:47:27Z","modified":"2026-03-23T04:54:43.333384Z","updated_at":"2026-11-02T16:58:41.463445Z"},{"id":"SUSE-SU-2025:01466-1","title":"Security update for rabbitmq-server","description":"This update for rabbitmq-server fixes the following issues:\n\n- CVE-2025-30219: Fixed XSS in an error message in Management UI (bsc#1240071)    \n    \nOther fixes:\n- Disable parallel make, this causes build failures\n","status":"published","published":"2025-06-11T12:47:33Z","modified":"2026-03-23T04:48:25.675789Z","updated_at":"2026-11-02T15:53:56.123059Z"},{"id":"SUSE-SU-2025:01548-1","title":"Security update for rabbitmq-server313","description":"This update for rabbitmq-server313 fixes the following issues:\n\n- CVE-2025-30219: incorrectly escaped virtual hostname present in error message could lead to XSS attack. (bsc#1240071)\n\nNon-security fixes:\n\n- Require rabbitmq-server313-plugins rather then rabbitmq-server-plugins. (bsc#1231656, bsc#1234763)\n","status":"published","published":"2025-06-11T12:47:27Z","modified":"2026-03-23T04:49:27.402456Z","updated_at":"2026-11-02T15:53:56.123059Z"},{"id":"SUSE-SU-2025:1466-1","title":"Security update for rabbitmq-server","description":"This update for rabbitmq-server fixes the following issues:\n\n- CVE-2025-30219: Fixed XSS in an error message in Management UI (bsc#1240071)    \n    \nOther fixes:\n- Disable parallel make, this causes build failures\n","status":"published","published":"2025-05-06T06:06:37Z","modified":"2026-03-23T04:50:38.656421Z","updated_at":"2026-11-02T15:53:59.381172Z"},{"id":"SUSE-SU-2025:1548-1","title":"Security update for rabbitmq-server313","description":"This update for rabbitmq-server313 fixes the following issues:\n\n- CVE-2025-30219: incorrectly escaped virtual hostname present in error message could lead to XSS attack. (bsc#1240071)\n\nNon-security fixes:\n\n- Require rabbitmq-server313-plugins rather then rabbitmq-server-plugins. (bsc#1231656, bsc#1234763)\n","status":"published","published":"2025-05-14T08:25:17Z","modified":"2026-03-23T04:48:07.22792Z","updated_at":"2026-11-02T15:53:59.381172Z"},{"id":"SUSE-SU-2026:20126-1","title":"Security update for rabbitmq-server","description":"This update for rabbitmq-server fixes the following issues:\n\nChanges in rabbitmq-server:\n\nUpdate to 4.1.5:\n\n* Highlights\n\n  - Khepri, an alternative schema data store developed to replace Mnesia,\n    has matured and is now fully supported (it previously was an experimental feature)\n  - AMQP 1.0 is now a core protocol that is always enabled. Its plugin is now a no-op that only exists to simplify upgrades.\n  - The AMQP 1.0 implementation is now significantly more efficient: its peak throughput is more than double than that of 3.13.x\n    on some workloads\n  - Efficient sub-linear quorum queue recovery on node startup using checkpoints\n  - Quorum queues now support priorities (but not exactly the same way as classic queues)\n  - AMQP 1.0 clients now can manage topologies similarly to how AMQP 0-9-1 clients do it\n  - The AMQP 1.0 convention (address format) used for interacting with with AMQP 0-9-1 entities is now easier to reason about\n  - Mirroring (replication) of classic queues was removed after several years of deprecation. For replicated messaging data types,\n    use quorum queues and/or streams. Non-replicated classic queues remain and their development continues\n  - Classic queue storage efficiency improvements, in particular recovery time and storage of multi-MiB messages\n  - Nodes with multiple enabled plugins and little on disk data to recover now start up to 20-30% faster\n  - New exchange type: Local Random Exchange\n  - Quorum queue log reads are now offloaded to channels (sessions, connections).\n  - Initial Support for AMQP 1.0 Filter Expressions\n  - Feature Flags Quality of Life Improvements\n  - rabbitmqadmin v2\n\n* Breaking Changes\n\n  - Before a client connection can negotiate a maximum frame size (frame_max), it must authenticate\n    successfully. Before the authenticated phase, a special lower frame_max value\n    is used.\n  - With this release, the value was increased from the original 4096 bytes to 8192\n    to accommodate larger JWT tokens.\n  - amqplib is a popular client library that has been using\n    a low frame_max default of 4096. Its users must upgrade to a compatible version\n    (starting with 0.10.7) or explicitly use a higher frame_max.\n    amqplib versions older than 0.10.7 will not be able to connect to\n    RabbitMQ 4.1.0 and later versions due to the initial AMQP 0-9-1 maximum frame size\n    increase covered above.\n  - The default MQTT Maximum Packet Size changed from 256 MiB to 16 MiB.\n  - The following rabbitmq.conf settings are unsupported:\n\n    - cluster_formation.etcd.ssl_options.fail_if_no_peer_cert\n    - cluster_formation.etcd.ssl_options.dh\n    - cluster_formation.etcd.ssl_options.dhfile\n\n  - Classic Queues is Now a Non-Replicated Queue Type\n  - Quorum Queues Now Have a Default Redelivery Limit\n  - Up to RabbitMQ 3.13, when an AMQP 0.9.1 client (re-)published a message to RabbitMQ, RabbitMQ interpreted the\n  - AMQP 0.9.1 x-death header in the published message's basic_message.content.properties.headers field.\n  - RabbitMQ 4.x will not interpret this x-death header anymore when clients (re-)publish a message.\n  - CQv1 Storage Implementation was Removed\n  - Settings cluster_formation.randomized_startup_delay_range.* were Removed\n  - Several Disk I/O-Related Metrics were Removed\n  - Default Maximum Message Size Reduced to 16 MiB\n  - RabbitMQ 3.13 rabbitmq.conf setting rabbitmq_amqp1_0.default_vhost is unsupported in RabbitMQ 4.0.\n  - RabbitMQ 3.13 rabbitmq.conf settings mqtt.default_user, mqtt.default_password,\n    and amqp1_0.default_user are unsupported in RabbitMQ 4.0.\n  - Starting with Erlang 26, client side TLS peer certificate chain verification settings are enabled by default in most contexts:\n    from federation links to shovels to TLS-enabled LDAP client connections.\n  - RabbitMQ Shovels will be able connect to a RabbitMQ 4.0 node via AMQP 1.0 only when the Shovel runs on a RabbitMQ node \u003e= 3.13.7.\n\n    * See https://github.com/rabbitmq/rabbitmq-server/releases/tag/v4.0.1\n    * and https://github.com/rabbitmq/rabbitmq-server/releases/tag/v4.1.0 for more info\n\n- Restore SLES logrotate file, (bsc#1246091)\n","status":"published","published":"2026-01-22T14:12:33Z","modified":"2026-03-23T04:52:36.665456Z","updated_at":"2026-11-02T15:54:01.610851Z"},{"id":"USN-7399-1","title":"rabbitmq-server vulnerability","description":"It was discovered that RabbitMQ Server's management UI did not sanitize\ncertain input. An attacker could possibly use this issue to inject code\nby performing a cross-site scripting (XSS) attack.\n","status":"published","published":"2025-03-31T15:36:32Z","modified":"2026-02-10T04:47:47Z","updated_at":"2026-11-02T16:58:19.988474Z"}]}}