RabbitMQ Server CVE-2026-67241

Requires AMQP 1.0 to be enabled (default in RabbitMQ 4.x) and an authenticated user who holds 'configure' permission on at least one exchange but lacks 'write' permission on the intended alternate exchange. Exploitation occurs specifically through the AMQP 1.0 management interface (PUT /exchanges/:name); the equivalent AMQP 0-9-1 channel path already enforces the check and is not affected. Limiting factors: the attacker must already have an authenticated foothold with configure rights, the impact is confined to routing otherwise-unroutable messages into an exchange, and there is no confidentiality or availability impact - only affected versions 4.2.0 through 4.2.8 and 4.3.0 through 4.3.2 are vulnerable.

This is a genuine but low-severity authorization flaw (CWE-862 missing authorization check), not a high-priority emergency. The vendor CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:N/VA:N/SC:L/SI:H/SA:N, base 4.8) correctly reflects that there is NO confidentiality, integrity, or availability impact on the vulnerable system itself - the only impact is a limited integrity effect on a subsequent system (the alternate exchange the attacker cannot legitimately write to). Exploitation is authenticated: the attacker must already possess 'configure' permission on at least one exchange, which the vector encodes as elevated privilege (PR:H); I assess this as more like a standard low-privilege authenticated grant (PR:L), a point worth verifying against RabbitMQ's permission model. There is no EPSS score, no CISA KEV listing, and no public exploit code provided in the intelligence, so this is 'no public exploit identified at time of analysis' - a real-but-narrow authz gap rather than a widely-exploitable issue. The AT:P (attack requirement) is appropriate because exploitation depends on the presence of unroutable messages and a configured alternate exchange. Net: real bug, confirmed and patched by the vendor, but low real-world urgency given the bounded impact and the requirement for an existing authenticated foothold.

An authenticated RabbitMQ user who has been granted only 'configure' permission on an exchange declares that exchange over the default-enabled AMQP 1.0 management interface (PUT /exchanges/:name) with an 'alternate-exchange' argument pointing at an exchange they lack 'write' permission on. Because the AMQP 1.0 path omits the read-on-source/write-on-target check the AMQP 0-9-1 path enforces, unroutable messages are then silently diverted into that unauthorized alternate exchange. No public exploit code is identified, and the attack requires an existing authenticated foothold with configure rights.