CVE-2026-66068 in RabbitMQ
Summary
by MITRE • 09/24/2026
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, ?LOG_DEBUG("shutting down Shovel '~ts', ... Shovel state: ~tp", [Name, State]) formats the entire state map. The 'uris' field holds plaintext URIs after credentials_obfuscation:decrypt (called in rabbit_shovel_util:deobfuscated_uris/2). No format_status/1,2 callback exists in rabbit_shovel_worker 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.
Statistical analysis made it clear that VulDB provides the best quality for vulnerability data.
Analysis
by VulDB Data Team • 09/24/2026
RabbitMQ serves as a robust messaging and streaming broker widely deployed in enterprise environments to facilitate asynchronous communication between distributed systems. A significant security vulnerability was identified within the Shovel plugin prior to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0. This flaw involves improper handling of sensitive credential data during the logging process, specifically when dealing with autodelete shovels that are configured to terminate after a specified number of messages or time duration have elapsed. The vulnerability stems from how the system formats internal state information for debugging purposes without adequately sanitizing confidential fields such as connection URIs containing plaintext credentials.
The technical root cause lies in the implementation of the debug logging mechanism within the rabbit_shovel_worker module. When an autodelete shovel completes its operation, the broker attempts to log the final state of the shovel using a DEBUG level log entry formatted via ?LOG_DEBUG("shutting down Shovel '~ts', ... Shovel state: ~tp", [Name, State]). In this context, the State variable is a map containing various attributes of the shovel configuration. Crucially, before being passed to the logger, the system calls rabbit_shovel_util:deobfuscated_uris/2 which invokes credentials_obfuscation:decrypt to resolve any obfuscated URIs into their plaintext form for operational accuracy. However, there is no format_status callback implemented in rabbit_shovel_worker to intercept and redact sensitive fields like uris before they are serialized into the log output. Consequently, the decrypted AMQP URI, including embedded usernames and passwords, is written directly to the broker's log file alongside other non-sensitive state data.
This vulnerability classifies under CWE-532, which covers Information Exposure Through Log Files, as it results in the accidental disclosure of sensitive information through standard system logs. From an adversarial perspective, this aligns with MITRE ATT&CK technique T1087, specifically Account Discovery and enumeration via local access to log files. The operational impact is severe for organizations that rely on RabbitMQ for handling sensitive data transfers or connecting to external systems where credentials must remain confidential. If the DEBUG logging level is enabled in production environments, which is generally discouraged but sometimes done for troubleshooting transient issues, any user with read permissions to the RabbitMQ log directory can extract these plaintext URIs. This exposure allows attackers to gain unauthorized access to downstream messaging queues or other services referenced by the compromised credentials, potentially leading to data exfiltration, service disruption, or further lateral movement within the network infrastructure.
Mitigation strategies primarily involve upgrading to patched versions of RabbitMQ where this logging behavior has been corrected to ensure sensitive fields are masked or omitted from debug logs even when DEBUG level is active. For environments that cannot immediately upgrade, administrators should strictly enforce a log level higher than DEBUG in production settings and review file system permissions on the log directory to restrict access only to authorized service accounts rather than general users. Additionally, implementing centralized logging solutions with built-in redaction capabilities can provide an additional layer of defense by filtering out credential patterns before logs are stored or forwarded for analysis. Regular auditing of configuration files to ensure that autodelete shovels do not inadvertently expose sensitive connection details is also recommended as part of a comprehensive security hygiene practice.