CVE-2026-66068: RabbitMQ: Shovel DEBUG log of full state exposes decrypted URIs
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.0, ?LOGDEBUG("shutting down Shovel '~ts', ... Shovel state: ~tp", [Name, State]) formats the entire state map. The 'uris' field holds plaintext URIs after credentialsobfuscation:decrypt (called in rabbitshovelutil:deobfuscateduris/2). No formatstatus/1,2 callback exists in rabbitshovelworker to redact it. Triggered when an autodelete shovel (src-delete-after = N) completes. With DEBUG logging enabled, autodelete-shovel completion writes the full shovel state map , including decrypted amqp://user:password@host/ URIs , to the broker log file. Preconditions include Shovel plugin enabled with URI-embedded credentials DEBUG log level (non-default) Autodelete shovel configuration Attacker has log read access. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0.
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.0
Event History
Frequently Asked Questions
Who is exposed to credential disclosure from this issue?
Exposure requires the Shovel plugin, a shovel configured with credentials embedded in its URI, DEBUG-level logging, and an autodelete shovel that completes. An attacker or user must also be able to read the broker log file containing the resulting entry.
Is a default RabbitMQ configuration affected?
DEBUG logging is a non-default precondition. The issue also requires a specifically configured autodelete shovel, so it is not triggered by ordinary shovel operation alone.
What can be done if upgrading is not immediately possible?
Disable DEBUG logging or avoid using URI-embedded credentials in Shovel configurations. Also restrict access to broker log files and avoid autodelete shovel configurations until the broker can be upgraded.
How can I determine whether credentials may already have been exposed?
Review broker logs generated while DEBUG logging was enabled for autodelete shovel completion messages that include a full Shovel state map. Check those entries for plaintext amqp://user:password@host/ URIs and rotate any credentials found in exposed log data.
Which versions contain the fix?
The issue is fixed in RabbitMQ 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0.