Il 29 settembre 2026 il progetto OpenSSL ha rilasciato aggiornamenti di sicurezza che correggono, secondo le cronache del settore, 14 vulnerabilità. Quella che conta di più è CVE-2026-84782, classificata come severità alta (CVSS 8.2 secondo CISA, citato da The Hacker News): una lettura fuori dai limiti (out-of-bounds read) nella gestione delle ritrasmissioni di DTLS, che può far uscire contenuto della memoria heap in chiaro verso la controparte o far andare in crash il processo. Al momento della pubblicazione non risultano attacchi in corso.

Cosa è successo

DTLS è la variante di TLS per UDP: lo usano VPN, WebRTC, telefonia e videochiamate, dispositivi IoT e alcune applicazioni di gaming e industriali. Nel difetto, quando l'invio di un grosso messaggio di handshake viene sospeso per limiti del trasporto e scatta il timer di ritrasmissione, il codice usa la posizione del messaggio sospeso nel buffer invece di ripartire dall'inizio del messaggio da rinviare. Ne deriva una lettura oltre l'area valida: i byte della heap finiscono nel pacchetto di handshake, quindi non cifrati, oppure il processo cade se si raggiunge memoria non mappata. La falla riguarda sia i client sia i server DTLS. Il codice vulnerabile è fuori dal perimetro del modulo FIPS. Le fonti consultate non indicano chi l'abbia scoperta.

Le versioni corrette sono:

  • OpenSSL 4.0.3 per il ramo 4.0;
  • 3.6.5 per il ramo 3.6;
  • 3.5.9 per il ramo 3.5 (LTS);
  • 3.4.8 per il ramo 3.4;
  • 3.0.23 per il ramo 3.0, disponibile solo con supporto premium; per 1.1.1 e 1.0.2 gli aggiornamenti sono riservati ai clienti con supporto esteso.

OpenSSL precisa che non esiste un workaround per chi non può aggiornare. Non è chiaro quanto sia facile far scattare le condizioni di ritrasmissione da remoto: l'avviso non fornisce metriche di sfruttabilità.

Come leggere questa notizia senza panico (e senza sottovalutarla)

Una falla "high" in OpenSSL ha un effetto diverso da una critica su un'appliance esposta. Qui il punto non è l'esecuzione di codice, ma la divulgazione di memoria: la heap può contenere frammenti di chiavi, token di sessione, credenziali o dati di altre connessioni, il che in scenari sfavorevoli è l'anticamera di un compromesso più serio. Tuttavia serve un servizio che usi DTLS e che sia raggiungibile dall'attaccante; per la gran parte dei siti web, che usano TLS su TCP, la falla non è rilevante.

La difficoltà vera è un'altra: OpenSSL raramente è "installato" in modo visibile. È dentro appliance, firewall, client VPN, applicazioni aziendali, container e immagini di terzi, ognuno con la propria versione incorporata. Aggiornare il sistema operativo non basta se il prodotto porta con sé la propria libreria.

Cosa significa per le aziende italiane

Per una PMI italiana l'azione utile non è "aggiornare OpenSSL", perché quasi nessuno lo gestisce direttamente, ma sapere dove è usato DTLS e chiedere ai fornitori lo stato delle loro patch. I casi più probabili sono le VPN aziendali basate su DTLS (molti client SSL-VPN usano DTLS per le prestazioni), i sistemi di videoconferenza e telefonia IP, i dispositivi IoT/OT con comunicazioni UDP e le applicazioni sviluppate internamente con librerie che incorporano OpenSSL.

Sul piano normativo, un patching tempestivo di una libreria crittografica rientra nelle misure di gestione delle vulnerabilità richieste dalla NIS2 (art. 21 della direttiva, recepita in Italia con il D.Lgs. 138/2024) e, per il settore finanziario, nel quadro di gestione del rischio ICT del DORA. Non è un obbligo di notifica in sé: lo diventa solo se la vulnerabilità viene sfruttata con effetti sui servizi o sui dati. Il valore per il consulente è la tracciabilità: un registro che mostri quando si è saputo della falla, chi ha valutato l'esposizione e quando è stata chiusa, che è esattamente ciò che un auditor o l'ACN chiederebbe.

Cosa fare subito

  • Mappare l'esposizione: individuare i servizi che usano DTLS (VPN, WebRTC, telefonia, IoT) e raggiungibili da reti non fidate; se non ce ne sono, la priorità scende.
  • Aggiornare dove OpenSSL è gestito da voi: server Linux, container e applicazioni proprie; riportare i pacchetti alle versioni 3.5.9, 3.6.5 o 4.0.3. Verificare con openssl version e con il gestore pacchetti della distribuzione, dove i backport possono non cambiare il numero di versione: controllare il changelog del pacchetto.
  • Chiedere ai fornitori: per appliance e software commerciale, richiedere conferma scritta sulla presenza della CVE-2026-84782 e sulla data del fix.
  • Ricostruire le immagini dei container e le pipeline di build che incorporano OpenSSL, perché un rebuild è necessario e non basta aggiornare l'host.
  • Registrare la valutazione nel registro delle vulnerabilità, anche quando la conclusione è "non esposti": è la prova di una gestione ordinata.

Il punto

La notizia non richiede interventi d'emergenza per la maggior parte delle aziende, ma è un buon test di maturità: sapete dire in un'ora dove, nella vostra infrastruttura, gira una certa libreria? Se la risposta è no, il problema da risolvere non è questa CVE, ma l'inventario del software.