RabbitMQ EUVD-2026-85651

Requires ALL of the following to co-occur, none of which is a default: (1) the RabbitMQ Shovel plugin enabled, (2) shovel URIs configured with credentials embedded directly in the URI (amqp://user:password@host/), (3) the broker log level raised to DEBUG (explicitly non-default), and (4) at least one shovel configured as autodelete via src-delete-after=N whose completion triggers the state-map log write. The attacker must also already possess read access to the broker's log file(s) or any downstream log aggregation. Because the vector is AV:L/PR:H, the effective exploitation ceiling is a locally-privileged actor or a log-consumer with existing filesystem/log access - there is no remote or unauthenticated path.

This is a genuinely low-to-moderate real-world priority despite disclosing credentials. The vendor CVSS 4.0 vector (AV:L/AC:L/AT:P/PR:H/UI:N/VC:H/VI:N/VA:N, 5.6 MEDIUM) is internally consistent with the description: exploitation is LOCAL (AV:L) because the attacker must already have read access to the broker's log files, requires HIGH privileges (PR:H) to reach that file/host, and carries an Attack Requirement (AT:P) because the leak only occurs when an autodelete shovel happens to complete. Impact is confidentiality-only (VC:H, VI:N, VA:N) - no integrity or availability effect. There is NO EPSS score, NO CISA KEV listing, and NO public exploit, so exploitation status is 'no public exploit identified at time of analysis' - treat this as a hardening/hygiene fix, not an emergency. The strongest limiting factor is the stacked non-default preconditions (DEBUG logging is explicitly non-default, Shovel plugin must be enabled, credentials must be embedded directly in URIs, and the shovel must be autodelete-configured), which together make widespread opportunistic exploitation implausible. No signals conflict; all point to a low-urgency, high-precondition information disclosure. The only caveat: once creds land in a log, they may propagate to centralized log aggregation/SIEM systems, widening who can read them beyond the local host.

An operator has RabbitMQ's Shovel plugin enabled with amqp://user:password@host URIs and, for troubleshooting, has raised the log level to DEBUG. When an autodelete shovel (src-delete-after=N) completes, the worker logs its full state map with the decrypted URI, writing the plaintext password to the broker log file. A user or process with read access to that log file (or to downstream log aggregation) then harvests the AMQP credentials. No public proof-of-concept is available.