// 1 ZERO-DAY · 2 CVE · 1 EXPLOIT NELLE ULTIME 24H→
CVE-2026-63073: una vulnerabilità format string nel modulo CMP di OpenSSL consente attacchi DoS senza autenticazione. Il rischio colpisce client con expected sender o pinned certificate.

Il 22 ottobre 2026 TrendAI Zero Day Initiative ha reso pubblica la vulnerabilità CVE-2026-63073 nel modulo Certificate Management Protocol (CMP) di OpenSSL. Una format string bug permette a un attaccante remoto di causare denial of service sui client che validano risposte server con expected sender o pinned certificate, senza richiedere autenticazione. La divulgazione coordinata arriva dopo circa sei mesi dal report al vendor.

Punti chiave
  • La vulnerabilità è classificata CWE-134 (Use of Externally-Controlled Format String) secondo il CVE Record ufficiale.
  • Il CVSS assegnato da ZDI è 6.5: rischio medio-alto, non critico, condizionato a specifiche configurazioni client CMP.
  • Il percorso vulnerabile si attiva solo con expected sender o pinned server certificate; il conseguimento di remote code execution è escluso dal CVE Record.
  • OpenSSL ha rilasciato un aggiornamento correttivo; il report iniziale al vendor risale all'8 aprile 2026.

Il meccanismo: quando il sender DN diventa format string

Il nucleo del difetto risiede nella funzione ossl_cmp_msg_check_update(), che gestisce la validazione delle risposte CMP. Quando il client riceve una risposta dal server, estrae il sender distinguished name (DN) dal messaggio e lo converte in stringa tramite X509_NAME_oneline(). Questa stringa viene poi passata direttamente come argumento formato a ERR_raise_data(), la routine di OpenSSL per la segnalazione errori.

Il problema è che i caratteri percento (%) sopravvivono intatti alla conversione. Un attaccante che controlla il sender DN può iniettare specificatori di formato come %s o %n, che raggiungono BIO_vsnprintf() senza corrispondenti argomenti variadici. Il risultato è la dereferenziazione di contenuti stack non controllati, con crash affidabile del processo client.

Il CVE Record descrive esplicitamente la catena: "Percent characters survive the conversion, so a sender DN such as CN=%s%n reaches BIO_vsnprintf() as an attacker-controlled format string with no matching variadic arguments". Questa precisione tecnica distingue CVE-2026-63073 da classifiche generiche di information disclosure.

Perché ZDI parla di disclosure ma il CVE Record nega letture controllate

L'advisory ZDI-26-789 titola la vulnerabilità come "Information Disclosure Vulnerability" e afferma che "this vulnerability allows remote attackers to disclose sensitive information on affected installations of OpenSSL". Il CVE Record offre una lettura più restrittiva: "The reliable consequence is a denial of service", esplicitando che "there is no controlled memory write, arbitrary-address read, or reliable path to remote code execution".

Questa discrepanza riflette una differenza di prospettiva tra le fasi di classificazione. ZDI valuta il potenziale informativo di una format string non controllata, dove la dereferenziazione stack può esporre frammenti di memoria in modo non deterministico. Il CVE Record, più conservativo, si limita al risultato affidabile e riproducibile: il crash del client CMP, quindi denial of service.

La lettura tecnica corretta è quella del CVE Record: il DoS è il danno documentato, mentre la disclosure informativa rimane un effetto collaterale non controllabile. Questo ha conseguenze operative: la priorità di mitigazione risiede nella continuità del servizio PKI, non nella protezione di dati specifici.

Le condizioni di attacco: non tutti i deployment sono esposti

Il percorso vulnerabile è condizionato. Secondo il CVE Record, "this path is only reached when the caller configures an expected sender or pins a server certificate, which is the normal configuration for a CMP client validating server responses". Client CMP che non impostano questi controlli — configurazioni server-to-server o test senza validazione — non attivano la funzione difettosa.

L'assenza di autenticazione richiesta amplifica comunque il rischio per i target esposti. Un endpoint CMP malevolo o intercettato (man-in-the-middle sui canali di provisioning) può rispondere con un sender DN crafted prima che il client verifichi l'identità del server. La vulnerabilità si manifesta nel momento stesso della validazione preliminare, quando il client elabora la risposta per estrarre metadati.

Il modulo CMP interessato è esplicitamente escluso dal boundary FIPS 140-2/140-3: "No FIPS module is affected, as the CMP implementation is outside the FIPS boundary". Questo esonera gli ambienti con validazione FIPS attiva da una revisione urgente su quel fronte, ma non mitiga il rischio operativo per le infrastrutture PKI che usano CMP fuori dal modulo certificato.

"The specific flaw exists within the handling of Distinguished Names within CMP messages. The issue results from the lack of proper validation of a user-supplied string before using it as a format specifier." — ZDI Advisory ZDI-26-789

Cosa fare adesso

  • Identificare i sistemi che utilizzano OpenSSL con il modulo CMP attivo e configurazione expected sender o pinned certificate: sono gli unici esposti secondo il CVE Record.
  • Applicare l'aggiornamento correttivo rilasciato da OpenSSL, verificando la presenza del fix per CVE-2026-63073 nelle release notes della versione installata.
  • Valutare la segmentazione temporanea dei client CMP da endpoint di provisioning non attendibili, in attesa del patching, se il coordinamento degli aggiornamenti richiede finestra di manutenzione.
  • Monitorare i log di crash dei processi CMP client: un arresto anomalo correlato a risposte server è indicatore di tentativo di exploit o di attività malevola sull'infrastruttura di gestione certificati.

Il contesto: sei mesi di coordinamento e una lezione sui protocolli legacy

La timeline rivela un coordinamento standard ma non breve: segnalazione al vendor l'8 aprile 2026, rilascio pubblico il 22 ottobre 2026. Il periodo di circa sei mesi riflette la complessità di patchare una libreria fondamentale come OpenSSL, dove ogni modifica al parser CMP richiede regression testing estensivo per non compromettere il provisioning certificati in produzione.

L'incidente ripropone una lezione ricorrente nei protocolli di gestione identità: i metadati di errore e di diagnostica sono superficie d'attacco tanto quanto i payload operativi. La funzione ERR_raise_data() è progettata per logging interno; il suo uso con input esterno non validato trasforma un'operazione di debug in vettore di compromissione. Le implementazioni CMP future — e più in generale i protocolli PKI come EST, SCEP, ACME — dovrebbero isolare rigorosamente i dati di protocollo dai format string di sistema.

La scelta di ZDI di classificare la vulnerabilità come information disclosure, nonostante il CVE Record enfatizzi il DoS, solleva anche una questione di metriche: il CVSS 6.5 di ZDI non cattura pienamente la specificità configurazionale del rischio. Un client CMP senza expected sender è funzionalmente non esposto, rendendo il punteggio generico potenzialmente sovrastimato per ampie porzioni del parco installato. Questo non riduce l'urgenza per i target effettivi, ma richiede accuratezza nel threat modeling interno.

Domande frequenti

La mia installazione OpenSSL è vulnerabile se non uso CMP?

No. Il difetto è confinato al modulo CMP e si attiva solo con specifiche configurazioni di validazione client. Il CVE Record esclude impatto su altri protocolli TLS/SSL o su applicazioni che non invocano le API CMP.

Perché ZDI e CVE Record discordano sull'impatto principale?

ZDI enfatizza il potenziale informativo di una format string non controllata; il CVE Record, più conservativo, documenta solo il DoS riproducibile. La lettura tecnica privilegia il CVE Record per la valutazione del rischio concreto.

Il modulo FIPS copre questa vulnerabilità?

No, e questo è documentato dal CVE Record: "No FIPS module is affected, as the CMP implementation is outside the FIPS boundary". La certificazione FIPS non estende la sua validazione al codice CMP di OpenSSL.

Fonti


Fonti e riferimenti
  1. zerodayinitiative.com
  2. cve.org