CVE-2026-67406: RabbitMQ: Federation and Shovel Gen-Servers Lack format_status Callback — Plaintext Credentials Exposed in Crash Dumps and sys:get_status
RabbitMQ is a messaging and streaming broker. From 4.0.0 until 4.3.3, 4.2.9, 4.1.14, and 4.0.23, Shovel does not format state logged by the crash reporter and can leave unencrypted credentials in a crash dump file. the shovel worker genserver processes does not implement the formatstatus/2 callback. When these processes crash (e.g., due to network partitions, connection failures), the OTP SASL error handler writes the full process state , including plaintext AMQP passwords and URIs , to the error log. This is particularly severe for the shovel worker, which stores deobfuscated plaintext URIs (including amqp://user:password@host format) in its genserver state for the entire process Automatic Credential Exposure: Shovel worker crashes (common during network partitions) automatically write plaintext upstream/downstream passwords to error logs No Special Configuration Needed: Unlike DEBUG logging, SASL error reports are always active Broad. This issue is fixed in versions 4.3.3, 4.2.9, 4.1.14, and 4.0.23.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
RabbitMQto a version that resolves this vulnerability.Fixed in 4.3.3
Event History
Frequently Asked Questions
Which deployments are exposed?
RabbitMQ deployments running affected versions from 4.0.0 up to the fixed releases are exposed if they use Shovel. The affected releases are fixed in 4.3.3, 4.2.9, 4.1.14, and 4.0.23.
What conditions cause credentials to be disclosed?
A Shovel worker GenServer crash causes the OTP SASL error handler to log its full process state. Crashes caused by network partitions or connection failures can therefore write plaintext AMQP passwords and URIs for upstream or downstream connections to error logs.
Does exploitation require debug logging or unusual configuration?
No. SASL error reports are always active, and the disclosure does not depend on debug logging or special configuration.
How can I determine whether credentials may already have been exposed?
Review RabbitMQ crash dump files and error logs for Shovel worker crash reports. The affected worker state can contain deobfuscated AMQP URIs in the form amqp://user:password@host, including plaintext passwords.
What should be done if affected Shovel workers have crashed?
Upgrade to the applicable fixed release, then treat credentials present in Shovel upstream or downstream URIs as potentially exposed and review the relevant logs and crash dumps.