CVE-2026-67231 in RabbitMQ
Riassunto
di VulDB • 24/09/2026
RabbitMQ è un broker di messaggistica e streaming. Prima delle versioni 3.13.15, 4.0.20, 4.1.11, 4.2.6 e 4.3.0, il plugin trust-store installa una verify_fun che sovrascrive {bad_cert, unknown_ca} / {bad_cert, selfsigned_peer} quando il certificato presentato "corrisponde" a uno nella whitelist. La chiave di corrispondenza è estratta tramite extract_issuer_id/1 → public_key:pkix_issuer_id/2 → {IssuerName, SerialNumber}; entrambi i campi sono presi letteralmente dal corpo del certificato presentato e non contengono materiale crittografico come chiavi pubbliche, SKI (Subject Key Identifier), fingerprint o firme. is_whitelisted/1 è una semplice ricerca tramite ets:member; il DER completo memorizzato viene utilizzato solo per la visualizzazione con list/0 e non viene mai confrontato con il certificato presentato. Poiché cacerts è [], il certificato nella whitelist non viene mai utilizzato come trust anchor (ancora di fiducia) anche per la validazione del percorso. Bypass dell'autenticazione TLS client: un attaccante che conosce l'Issuer DN + serial number di qualsiasi certificato in whitelist può connettersi utilizzando un certificato self-signed falsificato. I prerequisiti includono il plugin rabbitmq_trust_store abilitato e utilizzato come TLS verify_fun. L'attaccante deve conoscere o indovinare {Issuer, Serial} di almeno un certificato in whitelist (non segreto; esposto tramite CLI/log/qualsiasi copia del certificato). Questo problema è risolto nelle versioni 3.13.15, 4.0.20, 4.1.11, 4.2.6 e 4.3.0.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.