RabbitMQ CVE-2026-67218

Exploitation requires the rabbitmq_stream_management plugin to be enabled (non-default) and an authenticated account holding the management tag plus access to the target vhost - but notably NO configure permission on any resource. The specific flaw is that accept_content/2 (line 56) calls rabbit_stream_manager:create_super_stream directly after is_authorized, which only verifies the management tag and vhost access via is_authorized_vhost; the HTTP path entirely omits the rabbit_stream_utils:check_super_stream_management_permitted/4 call that the native stream-protocol reader performs to enforce configure on the exchange and each partition queue. Limiting factors: authentication is mandatory (management tag), the stream-management plugin must be enabled, and impact is confined to unauthorized creation of persistent stream resources (integrity only) with no data disclosure or denial of service.

This is a genuine but low-impact authorization flaw (CWE-862 missing authorization), not a high-severity issue. The vendor CVSS 4.0 base score is 2.1 (AV:N/AC:L/AT:P/PR:H/UI:N/VI:L), and every signal points to low real-world risk: it is authenticated (PR:H in the vendor vector; the description confirms a valid user with the management tag and vhost access is required), it has zero confidentiality and availability impact (VC:N/VA:N), and only limited integrity impact (VI:L) - the ability to create super-streams (an exchange plus N partition stream queues and bindings) despite lacking configure permission. There is no EPSS score, no CISA KEV listing, and no public POC in the provided data, so exploitation status is: no public exploit identified at time of analysis. The one nuance worth flagging: the vendor rates PR:H, but the management tag is a mid-tier RabbitMQ role rather than administrator, so PR:L is arguably more accurate - this raises the theoretical score slightly but does not change the priority. The AT:P attack requirement is justified because the rabbitmq_stream_management plugin must be enabled (non-default). Bottom line: a real privilege-escalation-from-'can view'-to-'can create persistent resources' bug worth patching in routine maintenance, but not an emergency; the low integrity impact and authenticated, plugin-gated precondition make it low priority.

An authenticated RabbitMQ user who has only the management tag and vhost access - but deliberately was NOT granted configure permission on any resource - sends a crafted request to the stream-management HTTP API to create a super-stream. Because the HTTP handler omits the check_super_stream_management_permitted authorization call that the native stream protocol enforces, the broker creates an exchange, N partition stream queues, and bindings cluster-wide, letting the user provision persistent resources they should not be able to create. No public POC is identified in the provided data.