CVE-2025-30219 - Exploiting XSS in RabbitMQ Management UI via Malicious Virtual Host Names
Intro:
RabbitMQ is a popular open-source messaging and streaming broker widely used for building scalable applications. Recently, a critical vulnerability CVE-2025-30219 was identified in versions prior to 4..3, making its management web UI susceptible to a sophisticated XSS (Cross-Site Scripting) attack due to improper handling of virtual host names. In this article, we'll explain what the issue is, how an attacker can exploit it, and what you can do to stay safe.
Vulnerability Overview
The root of the problem is how RabbitMQ’s management UI displays the name of a virtual host that has failed to start. When the platform shows an error message in its web interface, it includes the virtual host name—without proper escaping. This means that if the virtual host name contains malicious JavaScript code, it can execute in the user’s browser, leading to XSS attacks.
Importantly, a creative attacker can manipulate the on-disk representation of the virtual host, making it unrecoverable, and inject JavaScript which will trigger for administrators using the UI.
Affected Versions:
Tanzu RabbitMQ < 4..3 or < 3.13.8
Patched in:
RabbitMQ 4..3 and up
- Tanzu RabbitMQ 4..3 / 3.13.8 and up
How the Attack Works
To exploit CVE-2025-30219, an attacker needs access to the file system where RabbitMQ stores its virtual hosts (which is usually only accessible to trusted users, but may be possible in containerized or misconfigured environments).
`plaintext
Cause the Virtual Host to Fail:
The attacker sabotages the vhost on disk (e.g. by corrupting its data), ensuring it will not start successfully.
Trigger UI Error Notification:
When an admin or user logs in to the RabbitMQ management interface, the UI displays an error notification about the failed virtual host including the malicious name.
XSS Executed in Admin’s Browser:
The JavaScript executes in the admin’s browser, allowing the attacker to steal session cookies, hijack the session, or perform further attacks.
Here is what might be stored on disk as the virtual host name
<script>alert('Compromised!')</script>
And here’s how it could end up in the UI (unescaped)
<div class="notification error">
Error starting virtual host: <script>alert('Compromised!')</script>
</div>
If an admin opens the interface, the code inside <script> executes immediately.
Proof-of-Concept Steps
> Warning: This is for educational purposes only. Do not try this outside a test or lab setup!
Find RabbitMQ’s on-disk vhost file:
Usually in directories like /var/lib/rabbitmq or inside your Docker volume.
`bash
echo "" > /var/lib/rabbitmq/mnesia/rabbit@hostname/vhosts/MALICIOUS.overview
`
3. Corrupt the vhost so it fails to start (e.g., delete related data or introduce an invalid config).
Original References
- RabbitMQ Security Advisory (CVE-2025-30219)
- RabbitMQ Release Notes
- Official Patch Announcement
- OWASP XSS Guide
Remote Code Execution (in browsers)
- Cookie/session theft
Potential further internal attacks (if admin has access to other parts of the infrastructure)
The risk is high for environments where attackers can write files to RabbitMQ’s data directories.
How to Fix
- Upgrade immediately to at least RabbitMQ 4..3 or Tanzu RabbitMQ 4..3 / 3.13.8.
Conclusion
CVE-2025-30219 is a serious XSS vulnerability caused by the failure to escape user-controlled vhost names in error notifications within the RabbitMQ management UI. The flaw was fixed in v4..3, and all system administrators should patch immediately—especially in multi-tenant or cloud-hosted environments.
Stay vigilant and keep your message broker software up to date!
*If you want to read more on this, see the official RabbitMQ security page and always follow best practices for permissions and UI access.*
Timeline
Published on: 03/25/2025 23:15:36 UTC
Last modified on: 03/27/2025 16:45:46 UTC