Cloudanix VulnDB

CVE-2024-51988

Medium · 6.5

CVSS

6.5

EPSS

0.4%

Published

Nov 6, 2024

CISA due date

—

Cloudanix analysis

Schedule a fix SSVC: Track

A missing permission check let some users delete message queues they were not allowed to touch, risking disruption to messaging systems.

Exploitation
Remote Authenticated
Attacker needs
Low Privilege
Complexity
Low
Impact
Data Tampering
Component
Application
Class
Authorization Bypass
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

Missing authorization check allows any authenticated user with partial virtual host permissions and HTTP API access to delete queues without the required configure permission.

Why it matters to the business

Attackers can disrupt message queuing infrastructure, causing data loss, workflow interruptions, and operational downtime in systems relying on RabbitMQ for messaging.

How an attack unfolds

An attacker obtains valid credentials for a user that has limited permissions on a target virtual host and HTTP API access, then issues a queue deletion request through the management API that bypasses the configure permission check.

How to fix it

Upgrade to RabbitMQ 3.12.11 or Tanzu RabbitMQ 1.5.2, 3.13.0, or 4.0.0. If unable to upgrade, disable the management plugin and use alternative monitoring such as Prometheus and Grafana.

How to confirm the fix worked

Verify installed version matches a fixed release, then confirm that users without configure permission receive authorization errors when attempting queue deletion via the HTTP API.

Typical attack path

  1. Acquire valid credentials for a user with some virtual host permissions and HTTP API access
  2. Identify target virtual host and queue name
  3. Send authenticated HTTP DELETE request to the management API endpoint for the queue
  4. Queue is deleted despite lacking configure permission

How to detect it

Review RabbitMQ management API access logs for DELETE requests to queue resources from users lacking configure permission; correlate with authentication events and permission audit logs.

  • DELETE /api/queues/
  • management plugin access logs showing queue deletion by non-configure users

What your security team should do

  • Apply the listed version upgrades immediately
  • Audit all users with HTTP API access and restrict permissions to least privilege
  • Disable the management plugin if it is not required
  • Monitor management API logs for unexpected queue deletion attempts

The record

RabbitMQ is a feature rich, multi-protocol messaging and streaming broker. In affected versions queue deletion via the HTTP API was not verifying the `configure` permission of the user. Users who had all of the following: 1. Valid credentials, 2. Some permissions for the target virtual host & 3. HTTP API access. could delete queues it had no (deletion) permissions for. This issue has been addressed in version 3.12.11 of the open source rabbitMQ release and in versions 1.5.2, 3.13.0, and 4.0.0 of the tanzu release. Users are advised to upgrade. Users unable to upgrade may disable management plugin and use, for example, Prometheus and Grafana for monitoring.

Affected packages

Ecosystem Package Introduced Fixed
Bitnami rabbitmq 3.12.7 3.12.11
Debian:11 rabbitmq-server 0 No fix
Debian:12 rabbitmq-server 0 No fix
Debian:13 rabbitmq-server 0 No fix
Hex rabbit_common 3.12.7 3.12.11
Ubuntu:20.04:LTS rabbitmq-server 0 3.8.3-0ubuntu0.1
Ubuntu:22.04:LTS rabbitmq-server 0 3.9.27-0ubuntu0.1
Ubuntu:24.04:LTS rabbitmq-server 0 3.12.1-1ubuntu1
Ubuntu:24.10 rabbitmq-server 0 3.12.1-1ubuntu2

Related vulnerabilities