Описание
RabbitMQ is a messaging and streaming broker. Prior to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.1, The shovel management resource's is_authorized/2 delegates to rabbit_mgmt_util:is_authorized_monitor/2, which accepts the monitoring tag. But allowed_methods includes DELETE, and delete_resource/2 deletes / restarts shovel runtime parameters with no additional role check. A monitoring user , intended to have read-only visibility , can therefore delete or restart any shovel in any vhost they can see. A read-only monitoring user can delete or restart any dynamic shovel , a state-changing operation that the equivalent /api/parameters endpoint correctly restricts to policymaker. Preconditions include rabbitmq_shovel + rabbitmq_shovel_management plugins enabled Attacker has credentials with the monitoring tag. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.1.
A flaw was found in RabbitMQ. An authenticated monitoring user, who is intended to have read-only access, can exploit an improper authorization vulnerability. This allows them to delete or restart 'shovels' in any virtual host they can access, leading to a denial of service or disruption of message routing.
Отчет
Red Hat rates this flaw Moderate. To exploit it, an attacker needs broker credentials with the monitoring tag and network access to the management HTTP listener, and the broker must have the rabbitmq_shovel and rabbitmq_shovel_management plugins enabled. The monitoring role check has no per-vhost scope, so one monitoring account can delete or restart shovels in every virtual host on the broker, including vhosts where it holds no permissions. The attacker gains no read access and cannot create or modify shovels. The broker and unrelated clients keep running; the impact is limited to message flow through the targeted shovels until an administrator recreates them. An attacker who keeps the credentials can repeat the deletion, so rotating or removing the account should come before restoring the shovels.
Меры по смягчению последствий
Disable the shovel management extension on brokers that do not need to manage shovels over HTTP. Enable rabbitmq_shovel explicitly first so it stays active if it was only pulled in as a dependency: rabbitmq-plugins enable rabbitmq_shovel rabbitmq-plugins disable rabbitmq_shovel_management This removes the /api/shovels endpoint. Accounts with the policymaker or administrator tag can still delete shovels through /api/parameters, which enforces the correct role check. If the endpoint has to stay available, remove the monitoring tag from any account that should not be able to stop message flow.
Затронутые пакеты
| Платформа | Пакет | Состояние | Рекомендация | Релиз |
|---|---|---|---|---|
| Red Hat Hardened Images | rabbitmq-server4.2 | Will not fix | ||
| Red Hat OpenStack Platform 13 (Queens) | rabbitmq-server | Not affected | ||
| Red Hat OpenStack Platform 16.2 | rabbitmq-server | Not affected | ||
| Red Hat OpenStack Platform 17.1 | rabbitmq-server | Not affected | ||
| Red Hat OpenStack Platform 18.0 | rabbitmq-server | Not affected | ||
| Red Hat Hardened Images | rabbitmq-server4-3-main-4.3.6-1.hum1 | Fixed | RHSA-2026:67552 | 15.09.2026 |
Показывать по
Ссылки на источники
Дополнительная информация
Статус:
EPSS
7.1 High
CVSS3
Связанные уязвимости
RabbitMQ is a messaging and streaming broker. Prior to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.1, The shovel management resource's is_authorized/2 delegates to rabbit_mgmt_util:is_authorized_monitor/2, which accepts the monitoring tag. But allowed_methods includes DELETE, and delete_resource/2 deletes / restarts shovel runtime parameters with no additional role check. A monitoring user , intended to have read-only visibility , can therefore delete or restart any shovel in any vhost they can see. A read-only monitoring user can delete or restart any dynamic shovel , a state-changing operation that the equivalent /api/parameters endpoint correctly restricts to policymaker. Preconditions include rabbitmq_shovel + rabbitmq_shovel_management plugins enabled Attacker has credentials with the monitoring tag. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.1.
RabbitMQ is a messaging and streaming broker. Prior to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.1, The shovel management resource's is_authorized/2 delegates to rabbit_mgmt_util:is_authorized_monitor/2, which accepts the monitoring tag. But allowed_methods includes DELETE, and delete_resource/2 deletes / restarts shovel runtime parameters with no additional role check. A monitoring user , intended to have read-only visibility , can therefore delete or restart any shovel in any vhost they can see. A read-only monitoring user can delete or restart any dynamic shovel , a state-changing operation that the equivalent /api/parameters endpoint correctly restricts to policymaker. Preconditions include rabbitmq_shovel + rabbitmq_shovel_management plugins enabled Attacker has credentials with the monitoring tag. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.1.
RabbitMQ is a messaging and streaming broker. Prior to versions 3.13.1 ...
EPSS
7.1 High
CVSS3