CVE-2026-67418: 
RabbitMQ vulnerability analysis and mitigation

CVE-2026-67418 is an MQTT 5.0 protocol parsing vulnerability in RabbitMQ that allows an authenticated publisher to forcibly disconnect a victim subscriber's MQTT or Web MQTT connection by sending a PUBLISH packet containing the Request-Problem-Information property (MQTT property 0x17), which is only valid on CONNECT packets. Affected versions span RabbitMQ Server 3.13.0 through 3.13.18, 4.0.0 through 4.0.23, 4.1.0 through 4.1.14, 4.2.0 through 4.2.9, and 4.3.0 through 4.3.4. The vulnerability was disclosed on October 14, 2026, with the GitHub Security Advisory (GHSA-jv99-v328-mvmm) originally published August 18, 2026. It carries a CVSS v4.0 base score of 5.3 (Medium) (GitHub Advisory, Feedly).

The root cause is improper validation of MQTT 5.0 property applicability per packet type (CWE-248: Uncaught Exception; CWE-1286: Improper Validation of Syntactic Correctness of Input). In deps/rabbitmq_mqtt/src/rabbit_mqtt_packet.erl, the parse_prop/2 function accepted any MQTT property on any packet type without checking whether the property was valid for that packet type. Specifically, Request-Problem-Information (property 0x17) was accepted on PUBLISH packets despite the MQTT 5.0 specification restricting it to CONNECT. The broker's message container (mc_mqtt) preserved this inapplicable property through routing to matching subscribers; when the subscriber's egress path called serialise_prop/2, no matching clause existed for Request-Problem-Information, raising an unhandled function_clause exception that terminated the victim's MQTT connection. A self-contained proof-of-concept using raw socket frames was published in the advisory, demonstrating the attack against rabbitmq:4.1-management (GitHub Advisory, Fix Commit).

Exploitation allows one authenticated MQTT 5 publisher to forcibly close the TCP connection of any separately authenticated MQTT or Web MQTT subscriber sharing a matching topic subscription. The impact is limited to availability of the victim subscriber's connection — no confidentiality or integrity compromise was demonstrated, and broker-wide denial of service, queued message replay, or retained-message poisoning were not established. The publisher's connection and the broker process remain healthy after the attack, meaning the attacker can repeatedly target subscribers without losing their own session (GitHub Advisory).

A working proof-of-concept using raw MQTT socket frames was included in the GitHub Security Advisory and verified against RabbitMQ 4.1.8. Exploitation requires the attacker to be an authenticated MQTT 5 client with write permission to a topic that a victim subscriber is listening on — no elevated privileges beyond standard MQTT credentials are needed. There is no evidence of in-the-wild exploitation, no threat actor attribution, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is 0.0, and NVD's SSVC assessment classifies exploitation as "none" and the vulnerability as non-automatable (GitHub Advisory, Feedly).

1. Reconnaissance: Identify a RabbitMQ instance with MQTT (port 1883) or Web MQTT enabled and running a vulnerable version (3.13.0–3.13.18, 4.0.0–4.0.23, 4.1.0–4.1.14, 4.2.0–4.2.9, or 4.3.0–4.3.4).
2. Obtain credentials: Acquire valid MQTT credentials with write permission to at least one topic (e.g., default guest/guest on misconfigured instances).
3. Establish victim subscriber: Confirm a victim MQTT 5 client is subscribed to the target topic (or use a controlled subscriber to verify the attack path).
4. Connect as attacker: Open an MQTT 5 connection to the broker using the attacker's credentials (CONNECT frame with protocol version 5).
5. Send control PUBLISH: Send a valid QoS 0 PUBLISH to the target topic with an applicable property (e.g., Content-Type) to confirm the victim receives messages and the path is active.
6. Send attack PUBLISH: Send a crafted QoS 0 PUBLISH to the same topic containing Request-Problem-Information = 1 (property byte 0x17 0x01) in the properties field — a property valid only on CONNECT. Example raw frame: 30 07 00 01 74 02 17 01 78 (topic t, property length 2, Request-Problem-Information=1, payload x).
7. Observe result: The victim's MQTT TCP connection is closed by the broker due to the unhandled function_clause exception in serialise_prop/2; the attacker's connection and the broker remain operational. The broker log will show: {function_clause, [{rabbit_mqtt_packet,serialise_prop,['Request-Problem-Information',1],...}]} (GitHub Advisory).

• Logs: RabbitMQ broker log entries containing {function_clause, [{rabbit_mqtt_packet,serialise_prop, ['Request-Problem-Information',1], [{file,"rabbit_mqtt_packet.erl"},{line,559}]}, ... {rabbit_mqtt_processor,deliver_one_to_client,3,...}]} — this is the primary indicator of exploitation attempts.
• Logs: Repeated unexpected MQTT client disconnections for subscriber sessions without corresponding client-initiated DISCONNECT frames, particularly correlated with PUBLISH activity from a specific publisher client ID.
• Network: MQTT PUBLISH packets (first byte 0x30) on port 1883 or Web MQTT port containing property byte 0x17 (Request-Problem-Information) in the properties section — this property is protocol-invalid on PUBLISH and should never appear in legitimate traffic.
• Process: Erlang process crash reports in the RabbitMQ node logs referencing rabbit_mqtt_reader or rabbit_mqtt_processor terminating due to function_clause errors in rabbit_mqtt_packet.erl (GitHub Advisory).

Upgrade RabbitMQ Server to one of the patched versions: 3.13.19, 4.0.24, 4.1.15, 4.2.10, or 4.3.5, which enforce strict per-packet-type property validation at ingress, disconnecting the offending publisher rather than crashing the subscriber. No configuration-based workaround is available; disabling MQTT entirely would prevent exploitation but is not practical for MQTT-dependent deployments. As a defense-in-depth measure, restrict MQTT topic write permissions to only trusted, known clients to reduce the pool of potential attackers (GitHub Advisory, Fix PR).