RabbitMQ Management CVE-2026-44839

The attacker must hold a valid RabbitMQ administrator account (PR:H per CVSS vector) with sufficient permissions to create virtual hosts - this is a non-default capability in hardened deployments where vhost creation is restricted. The management plugin must be enabled and the management UI must be accessible to the attacker over the network (AV:N). A separate administrator (victim) must actively load the affected management UI page that renders the malicious vhost name (UI:A - active user interaction). Exploitation is therefore limited to environments where: (1) the management plugin is running, (2) the attacker has admin credentials, and (3) a second admin session views the affected page. Exploitation is NOT possible against default RabbitMQ installations that restrict management UI network exposure or limit vhost creation permissions.

The CVSS 4.0 base score of 5.6 reflects a materially constrained attack surface. The vector AV:N/AC:H/AT:N/PR:H/UI:A encodes three significant limiting conditions: high attack complexity, high privilege requirements (admin-level access to create vhosts), and mandatory active user interaction by a victim admin. This is not a remotely exploitable unauthenticated issue - the attacker must already hold administrative credentials and rely on a second admin loading the affected management page. The confidentiality impact (VC:H) is consistent with session hijacking or credential capture within the management plane, but integrity and availability are unaffected. No EPSS data was provided in the intelligence feed, and the vulnerability is not listed in the CISA KEV catalog, indicating no confirmed widespread exploitation. The practical risk is low for organizations that restrict management UI access and enforce least-privilege admin accounts, but elevated in multi-tenant or shared-admin environments where different administrators create vhosts and others review them.

An attacker who has obtained administrator-level credentials to a RabbitMQ instance creates a virtual host with a name containing an XSS payload (e.g., a crafted string that breaks out of an HTML attribute context in the management UI). When a second administrator subsequently loads the vhosts listing or vhost detail page in the management console, the malicious script executes in their browser session, potentially exfiltrating the victim's session cookie or management credentials back to the attacker. No public proof-of-concept code has been identified at time of analysis.