RabbitMQ is a messaging and streaming broker

Why it is Yellow

• CVSS 6.5 medium
• Public exploit or proof of concept referenced

References

• https://github.com/rabbitmq/rabbitmq-server/commit/0f3defd176e027f54f447beee168d906d4f109b6
• https://github.com/rabbitmq/rabbitmq-server/commit/eb11bc44005fd6d327a78bf171bc598207778c9b
• https://github.com/rabbitmq/rabbitmq-server/releases/tag/v4.2.9
• https://github.com/rabbitmq/rabbitmq-server/releases/tag/v4.3.3
• https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-2hm4-4438-49q8
• https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-2hm4-4438-49q8

Original description

RabbitMQ is a messaging and streaming broker. From 4.1.0 until 4.3.3, 4.2.9, and 4.1.11, Stream Management Super-Stream Binding Keys Allocation Allows Low-Privilege Node Denial of Service. rabbitMQ 4.3.1 with rabbitmqstreammanagement enabled accepts PUT /api/stream/super-streams/{vhost}/{name} requests from an authenticated management user that can access the target vhost. When the request body contains the binding-keys field, the handler parses the attacker-controlled comma-separated string and builds the full stream-name list before checking whether the user has permission to configure the resulting streams. A low-privileged management user with vhost access but no configure, write, or read permission can therefore force large transient allocations before the resource permission check. In a 768 MB memory-limited container, one HTTP PUT with about 4.5 MB of JSON body killed the RabbitMQ container with Docker state exited true An authenticated low-privileged management user can kill a memory-limited RabbitMQ node with one HTTP This issue is fixed in versions 4.3.3, 4.2.9, and 4.1.11.