RabbitMQ: OAuth2 silent verify_none fallback for JWKS fetch
- Published
- Last modified
- Where the record stands: published, rejected by its publisher, or superseded by another id.What do these mean? →
- published
- Whether CISA lists it in its Known Exploited Vulnerabilities catalog: proof that attackers are using it.What do these mean? →
- Not listed in CISA KEV
- Fix
- Fixed in 3.13.15, 4.0.20, 4.1.11, 4.2.6
- Whether working attack code is public (Exploit-DB, Metasploit, Nuclei or GitHub). Public code makes attacks easier.What do these mean? →
- None on Exploit-DB, Metasploit or GitHub
- Exploitation: none
- Automatable: no
- Technical impact: total
Summary
RabbitMQ is a messaging and streaming broker. Prior to versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0, When no CA bundle is available, ssl_options/1 falls back to [{verify, verify_none}] with no warning. An attacker in a man-in-the-middle position can forge the JWKS response, which leads the broker to accept arbitrary JWTs. Preconditions include The OAuth2 plugin must be in use with no cacertfile configured and the OS CA bundle empty or unreadable (for example, in a minimal container), and the attacker must hold a network man-in-the-middle position.. This issue is fixed in versions 3.13.15, 4.0.20, 4.1.11, 4.2.6, and 4.3.0.
Timeline
- CVE published
- CISA SSVC assessment
Exploitation: none · Automatable: no · Technical impact: total
- Record last updated
Affected versions
- rabbitmq rabbitmq-server
From 3.13.0 · fixed in 3.13.15; From 4.0.0 · fixed in 4.0.20; From 4.1.0 · fixed in 4.1.11; From 4.2.0 · fixed in 4.2.6
- rabbitmqBitnami
From 3.13.0 · fixed in 3.13.15; From 4.0.0 · fixed in 4.0.20; From 4.1.0 · fixed in 4.1.11; From 4.2.0 · fixed in 4.2.6