CVE-2026-67233: RabbitMQ: Monitoring-tag user can DELETE shovels
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 isauthorized/2 delegates to rabbitmgmtutil:isauthorizedmonitor/2, which accepts the monitoring tag. But allowedmethods includes DELETE, and deleteresource/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 rabbitmqshovel + rabbitmqshovelmanagement 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 3.13.15 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.0.20 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.1.11 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.2.6 - Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.3.1
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments before 3.13.15, 4.0.20, 4.1.11, 4.2.6, or 4.3.1 are affected when both the rabbitmq_shovel and rabbitmq_shovel_management plugins are enabled. Exposure is limited to vhosts that a user with the monitoring tag is permitted to see.
What access does an attacker need?
An attacker needs valid credentials for a RabbitMQ user assigned the monitoring tag. No policymaker role is required for the affected shovel-management DELETE operation.
What can an unauthorized monitoring user do?
They can delete or restart dynamic shovels in any vhost visible to them. This can disrupt shovel operation through a state-changing action despite the monitoring role being intended for read-only visibility.
What should be done if an upgrade cannot be applied immediately?
Restrict or remove monitoring-tag credentials for users that can access vhosts containing dynamic shovels, and limit their vhost visibility where possible. Consider disabling the shovel management capability if it is not needed; the issue requires both the shovel and shovel-management plugins.
How can administrators identify potentially affected access?
Review RabbitMQ users with the monitoring tag and determine which vhosts they can see, then identify dynamic shovels in those vhosts. Systems running a version earlier than the listed fixed releases with both required plugins enabled should be treated as affected.