RabbitMQ CVE-2026-67221

Exploitation requires all of the following: the Shovel plugin must be enabled AND at least one AMQP 1.0 shovel must be configured using credentials embedded directly in the connection URI (the AMQP 0-9-1 shovel is unaffected because it strips credentials via amqp_uri:remove_credentials before storage). Reading the exposed credential requires an authenticated account holding the 'monitoring' management tag, accessing GET /api/shovels or running rabbitmqctl shovel_status. Limiting factors: it is a passive read-only disclosure with no integrity/availability impact; the non-default URI-embedded-credential configuration and the monitoring-tag authentication requirement both narrow the exploitable population; brokers that reference shovel credentials indirectly (not embedded in the URI) are not affected.

This is a genuine but modest-priority information-disclosure issue, not a high-urgency flaw. The vendor CVSS 4.0 base score is 5.9 (MEDIUM) with vector AV:N/AC:L/AT:P/PR:H/UI:N and confidentiality-only impact (VC:H, VI:N, VA:N) - meaning the only consequence is exposure of a stored credential, no integrity or availability effect. Multiple signals point to constrained real-world risk: the AT:P (Attack Requirements: Present) metric reflects that a specific non-default configuration must exist (Shovel plugin enabled with AMQP 1.0 shovels defined using URI-embedded credentials), and reading the exposed data requires an authenticated user holding the monitoring management tag. There is no EPSS score, no CISA KEV listing, and no public exploit code in the provided data, so exploitation status is 'no public exploit identified at time of analysis' - this is not evidence of active exploitation. The CWE-312 (cleartext storage) classification and description are internally consistent with the confidentiality-only vector. One caveat worth verifying: the vendor sets PR:H, but the described precondition is merely the 'monitoring' tag, which is a mid-tier read-oriented management privilege rather than full administrator - this leans toward PR:L, and I have assessed it as such below. No data is missing that changes the overall MEDIUM classification, but note the exposed password is that of the shovel's upstream/downstream broker connection, so blast radius depends on what that credential grants.

An authenticated RabbitMQ user with the monitoring tag (e.g. a low-trust operator or a compromised monitoring service account) queries GET /api/shovels or runs rabbitmqctl shovel_status on a broker where an AMQP 1.0 shovel was configured with credentials embedded in its connection URI. The raw URI is returned including the plaintext password, handing the attacker the remote broker's connection credentials. No public exploit code is required or noted; the exposure is a simple authenticated API read against a susceptible configuration.