CVE-2026-67410 is a high severity (CVSS 7.1) information exposure flaw in the RabbitMQ management UI. When OAuth2 is enabled with a client secret, the secret is served in an unauthenticated JavaScript endpoint. Upgrade to RabbitMQ 4.2.9 or 4.3.3, then rotate the secret.
What's affected
The record says RabbitMQ from 4.2.0 until 4.3.3 and 4.2.9 is affected, and fixed in 4.3.3 and 4.2.9. I could not retrieve a dedicated advisory page for this CVE. The 4.2.9 release notes on GitHub were retrieved, but they do not name this CVE, so check the project advisory list for confirmation.
The condition is specific. The record says OAuth2 authentication must be enabled for the management UI, and the identity provider flow must use a client secret. Brokers that use no OAuth2, or a flow without a secret, do not match the description.
The record places the secret in the JavaScript served from the bootstrap path for OAuth in the management plugin, which is reachable without logging in. Anyone who can reach the management port can read it.
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 see whether the secret setting exists in your configuration:
grep -rn "oauth_client_secret\|management.oauth" /etc/rabbitmq/
If your configuration sets a client secret for the management UI, assume anyone who could reach the port could have read it. Check network rules for the management port as well. A management UI on an internal network is a smaller exposure than one on the internet.
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 or 4.2.9 or later.
- Rotate the OAuth2 client secret at your identity provider after upgrading, because the old value may already have been read.
- Limit access to the management port to administrators, through a firewall, a VPN or a reverse proxy with authentication.
- Review identity provider logs for unexpected use of the client credentials.
- Check with your identity provider whether the management UI flow can run without a client secret, so no secret has to reach the browser.
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-200, exposure of sensitive information to an unauthorized actor. The management UI needs some configuration in the browser to start a login, and the record says the configuration script included the client secret value. A secret that reaches a browser is not a secret.
OAuth2 client secrets belong to a server side component. Putting them in a page that loads before login hands them to any visitor. The impact depends on what the client can do at your identity provider. The record does not mark this CVE as known exploited.
Quick check
Is rotating the secret really needed after upgrading?
Yes. The upgrade stops further exposure, but any copy already read stays valid until the secret changes.
Does this affect brokers that do not use OAuth2?
The record describes the issue only when OAuth2 is enabled for the management UI with a flow that uses a client secret.
Sources
- https://github.com/rabbitmq/rabbitmq-server/releases/tag/v4.2.9
- Record: NVD entry for CVE-2026-67410 (score 7.1, HIGH)
Last reviewed: 18 October 2026.
