RabbitMQ 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 out-of-memory killer-like mechanism. This vulnerability has been patched in versions 3.11.24 and 3.12.7.
The product does not properly control the allocation and maintenance of a limited resource.
| Name | Vendor | Start Version | End Version |
|---|---|---|---|
| Rabbitmq | Vmware | * | 3.11.24 (excluding) |
| Rabbitmq | Vmware | 3.12.0 (including) | 3.12.7 (excluding) |
| Red Hat OpenStack Platform 17.1 for RHEL 9 | RedHat | rabbitmq-server-0:3.9.10-3.el9ost | * |
| Rabbitmq-server | Ubuntu | bionic | * |
| Rabbitmq-server | Ubuntu | devel | * |
| Rabbitmq-server | Ubuntu | esm-infra/focal | * |
| Rabbitmq-server | Ubuntu | focal | * |
| Rabbitmq-server | Ubuntu | jammy | * |
| Rabbitmq-server | Ubuntu | lunar | * |
| Rabbitmq-server | Ubuntu | mantic | * |
| Rabbitmq-server | Ubuntu | noble | * |
| Rabbitmq-server | Ubuntu | oracular | * |
| Rabbitmq-server | Ubuntu | plucky | * |
| Rabbitmq-server | Ubuntu | trusty | * |
| Rabbitmq-server | Ubuntu | upstream | * |
| Rabbitmq-server | Ubuntu | xenial | * |
Mitigation of resource exhaustion attacks requires that the target system either:
The first of these solutions is an issue in itself though, since it may allow attackers to prevent the use of the system by a particular valid user. If the attacker impersonates the valid user, they may be able to prevent the user from accessing the server in question.
The second solution is simply difficult to effectively institute – and even when properly done, it does not provide a full solution. It simply makes the attack require more resources on the part of the attacker.