La release di manutenzione 2.7.8 di OpenVPN (discussione pubblica datata 7 ottobre 2026) raggruppa tre correzioni con tag CVE più una modifica di robustezza di tls-crypt-v2 che deliberatamente non porta un ID CVE. Questa nota di sicurezza unisce i principali advisory in modo che gli operatori possano dare priorità ai client Windows e Android, agli strumenti per i certificati e ai server DCO multi-client, senza trattare i blog di marketing come unica fonte di verità.

Encrypt-then-MAC authenticated encryption construction diagram
Fonte: Wikimedia Commons (RokerHRO) — Crittografia autenticata EtM

Fonti primarie

CVE-2026-88964 — underflow della domain search

La wiki della community afferma che un integer underflow in OpenVPN su Windows e Android consente a server remoti autenticati di causare denial of service o memory disclosure tramite opzioni domain search appositamente confezionate nella gestione di PUSH_REPLY. Si tratta di una classe di bug classica «trusted peer, hostile options»: l’autenticazione è già riuscita, ma il parsing delle opzioni si è ancora fidato eccessivamente dell’aritmetica delle lunghezze. L’impatto è denial of service e potenziale memory disclosure, non una pretesa di remote code execution libera nel testo pubblico della wiki. La correzione è inclusa in 2.7.8.

I difensori devono presupporre che qualsiasi client ancora sulla 2.7.7 o precedente nella finestra interessata resti esposto quando si connette a un endpoint ostile ma autenticato, inclusi concentratori aziendali compromessi e server di laboratorio scarsamente controllati. La precondizione è facile da fraintendere: non si tratta di uno sconosciuto non autenticato che bombarda di pacchetti un client casuale. Richiede che il client si fidi già del peer abbastanza da completare l’autenticazione e accettare le opzioni PUSH_REPLY. Concentratori compromessi, laboratori di test malevoli e profili emessi in modo errato restano percorsi realistici. Non gonfiare l’advisory in una narrativa di remote-code-execution non autenticata che la wiki OpenVPN non sostiene.

CVE-2026-84790 — byte NULL nei subject dei certificati

Padlock symbol representing encrypted network traffic
Fonte: Wikimedia Commons — Padlock.svg

Linux Compatible riferisce che i certificati con byte NULL incorporati nelle stringhe subject vengono ora rifiutati. Le build OpenSSL rischiavano in precedenza parser che si fermano al primo byte NULL; le build mbedTLS già rifiutavano tali certificati. Vivek Parikh di BreachX ha segnalato il problema; Max Fillinger ha implementato la correzione. Impatto operativo: i certificati archiviati o confezionati in modo malevolo che un tempo «funzionavano» su OpenSSL possono fallire dopo l'aggiornamento. I team degli strumenti per certificati dovrebbero analizzare gli inventari prima di un rollout di massa e trattare i fallimenti improvvisi di handshake dopo la 2.7.8 come un segnale di igiene dei certificati piuttosto che come un glitch di rete casuale.

Quel rifiuto può anche interrompere gli strumenti legacy che hanno accidentalmente incorporato caratteri NUL durante la generazione delle stringhe subject. L'interruzione è auspicabile dal punto di vista della sicurezza del parser, ma le finestre di change richiedono un passaggio di inventario. Abbina l'aggiornamento OpenVPN a revisioni del testo dei certificati o a report PKI aziendali che segnalano byte non stampabili nei subject prima di dichiarare completo il rollout.

CVE-2026-84256 — quoting di Windows CreateProcess

La versione 2.7.8 prosegue il hardening intorno al quoting della riga di comando di Windows, in modo che i caratteri speciali per cmd.exe non possano innescare l'espansione di variabili all'interno di argomenti tra virgolette. Lev Stipakov ha implementato il lavoro; Darren Carreras lo ha segnalato. Lo stesso numero CVE è stato parzialmente affrontato nella 2.7.7, quindi la 2.7.8 è un secondo passaggio sullo stesso percorso piuttosto che un bug Windows non correlato. Gli script che invocano la shell intorno a OpenVPN su Windows meritano test di regressione dopo l'aggiornamento, soprattutto quando passano percorsi di profilo controllati dall'utente o argomenti helper tramite CreateProcess.

Robustezza di tls-crypt-v2 senza un CVE

Durante gli handshake tls-crypt-v2, OpenVPN poteva tentare di aggiungere una chiave client wrappata anche quando non era disponibile alcun materiale di chiave, fidandosi troppo di una richiesta di reinvio del peer. La modifica della 2.7.8 interrompe quella fiducia cieca. Secondo le indicazioni della Computer Resilience Agency dell'Italia, come riportate da Linux Compatible, «un server malevolo può impedire al client di funzionare correttamente» è stato trattato come un degrado di robustezza piuttosto che come un CVE di riservatezza o integrità. Gli operatori dovrebbero comunque installarla: gli attacchi alla disponibilità contro i client VPN sono operativamente costosi anche quando sono privi del lustro di un CVE, e i sistemi di change-management dovrebbero tracciare esplicitamente l'hardening non-CVE.

L'identificatore mancante illustra una lezione più ampia per i programmi di sicurezza VPN. Le policy che omettono gli ID CVE per problemi di sola disponibilità contro peer già autenticati nasconderanno parte della 2.7.8 a meno che gli operatori non registrino voci esplicite di robustezza. L'articolo del 7 ottobre 2026 di Linux Compatible è un contesto secondario utile, ma i ticket di change dovrebbero comunque collegare le pagine OpenVPN ReleaseHistory e il wiki CVE come evidenza primaria.

Lavoro adiacente sulla disponibilità che gli operatori non dovrebbero ignorare

Oltre all'elenco CVE, la 2.7.8 modifica il comportamento multi-client e dell'offload del data-channel. Le route per-client vengono rimosse al momento effettivo di uscita anziché durante la pulizia ritardata multi-istanza, correggendo una race che poteva lasciare i sistemi senza route. Un socket netlink dedicato separa il lavoro sincrono dalle notifiche asincrone. Quando un'operazione sul peer o sulla chiave fallisce dopo che il peer è già scomparso dal kernel, OpenVPN riavvia una singola istanza invece di uccidere l'intero server. Quelle correzioni di disponibilità e correttezza contano tanto quanto i CVE per i server di grandi dimensioni sotto tempeste di riconnessione, e sono state segnalate in parte dal team Access Server di OpenVPN Inc. secondo Linux Compatible.

Cosa questo non è

  • Non è un advisory WireGuard. Le discussioni WireGuard separate di ottobre 2026, incluse le patch handshake-response su LKML e il CVE-2026-13735 sull'autenticazione keepalive di Zephyr, appartengono alle proprie note.
  • Non marketing delle note di rilascio del fornitore per un marchio VPN commerciale destinato ai consumatori.
  • Non un'autorizzazione a eseguire server non attendibili «per testare» la classe di bug del server autenticato.

Anche nell'ottobre 2026 ci sono state discussioni relative a WireGuard che gli operatori possono confondere con le patch di OpenVPN. Il thread handshake-response su LKML e il problema di keepalive di Zephyr CVE-2026-13735 su NVD sono reali, ma non applicano patch a OpenVPN 2.7.8 e OpenVPN 2.7.8 non li risolve. Mantieni gli inventari suddivisi per binario: OpenVPN community, WireGuard in-kernel, WireGuard userspace, stack Zephyr e app VPN mobili proprietarie. Mescolare queste linee di sviluppo in un unico foglio di calcolo «VPN CVE» è il modo in cui i team non individuano i client OpenVPN per Windows e Android che CVE-2026-88964 nomina effettivamente.

Checklist del difensore

  1. Fai l'inventario dei client OpenVPN per Windows e Android nella finestra 2.7.x e distribuisci la 2.7.8 o successiva.
  2. Analizza gli archivi dei certificati alla ricerca di byte NULL incorporati prima dell'aggiornamento delle flotte OpenSSL.
  3. Esercitati con i riavvii DCO e multi-client su un nodo di staging per assorbire i cambiamenti di comportamento del riavvio delle istanze.
  4. Mantieni le implementazioni tls-crypt-v2 su build con patch anche quando una correzione è priva di un ID CVE.
  5. Cita gli advisory primari nei ticket di modifica anziché solo i blog secondari.
  6. Separa i ticket dei client OpenVPN dai ticket del kernel WireGuard e di Zephyr.

In sintesi: considera OpenVPN 2.7.8 come un pacchetto di sicurezza e disponibilità per il parsing del canale di controllo, l'igiene dei certificati, il quoting dei processi Windows e la stabilità dell'offload del canale dati sui server di grandi dimensioni. Poi verifica con i tuoi hash dei pacchetti e i laboratori di staging prima di dichiarare chiuso il cluster CVE.