CVE-2026-67407 is a high severity (CVSS 7.1) authorization flaw in RabbitMQ, an incomplete fix for CVE-2026-44838. A low privileged MQTT user who controls its client ID can broaden topic access when permission templates embed the client ID inside a bracket expression. Fixed in 4.3.3, 4.2.9, 4.1.14 and 4.0.23.
What's affected
Fixed versions are the same in the record and the GitHub advisory (GHSA-q46v-hrvq-hp24): 4.3.3, 4.2.9, 4.1.14 and 4.0.23.
The affected ranges are worded differently, and both are reported here. The record says "from 4.0.0 until 4.3.3 and 4.2.9 and 4.1.14 and 4.0.23". The advisory is more precise: 4.3.2 up to but not including 4.3.3, 4.2.0 up to 4.2.9, 4.1.0 up to 4.1.14, and 4.0.0 up to 4.0.23. In practice both say to move to the fixed release on your line.
Severity differs. The record scores it 7.1 (High). The GitHub advisory labels it Moderate.
You are only in scope if you use MQTT with topic permissions defined as templates that place the client ID variable inside a square bracket character class. Many deployments do not.
How to check if you're exposed
rabbitmqctl version
rabbitmq-diagnostics server_version
Run these on each node. In containers, run them with docker exec or kubectl exec against the broker pod, and also check the image tag you deploy. Mixed version clusters during a rolling upgrade are common, so check every node, not just one.
Then check whether the configuration pattern exists. Look at the topic permissions on your MQTT users:
rabbitmqctl list_topic_permissions -p /
Run it for each virtual host. Check for templates that put the client ID variable inside square brackets. If none do, the specific condition from the advisory is absent, but you should still plan the upgrade.
A quicker route for a whole project is the free in-browser dependency scan at Gold. Paste a manifest or lockfile and it matches each dependency against known CVEs, including ones pulled in indirectly.
What to do now
- Upgrade to 4.3.3, 4.2.9, 4.1.14 or 4.0.23, whichever matches your release line.
- Review MQTT topic permission templates and remove any that embed the client ID variable inside a bracket expression.
- Restrict who can choose a client ID, for example by enforcing a naming pattern at the authentication layer.
- Audit MQTT users for read and write access to topics they should not reach.
- Read the advisory for CVE-2026-44838 to confirm you also have that earlier fix.
Reachability analysis helps with ordering the work. Knowing whether your code actually calls the affected path tells you which services to patch first.
Why it matters
The class is CWE-862, missing authorization. The earlier fix escaped special characters in expanded variables so that a client ID could not rewrite a permission pattern. The escape routine missed the hyphen. Inside a character class, a hyphen means a range, so a client ID containing it can match more topics than the template author intended.
It is a good example of an incomplete fix. A patch that escapes most special characters leaves a small gap that only matters in one syntactic position. The record does not mark this CVE as known exploited.
Quick check
Do I need MQTT enabled to be affected?
The advisory names the rabbitmq_mqtt plugin topic permissions, so a broker without MQTT users and topic permission templates is not in the described scenario.
Why do the record and advisory list different ranges?
The record uses a broad lower bound of 4.0.0, while the advisory lists a tighter range per release line. Both agree on the fixed releases.
Sources
- https://github.com/rabbitmq/rabbitmq-server/security/advisories/GHSA-q46v-hrvq-hp24
- Record: NVD entry for CVE-2026-67407 (score 7.1, HIGH)
Last reviewed: 18 October 2026.
