Tecnologia VPN

OpenVPN 2.7.8 è stato rilasciato intorno al 6–7 ottobre 2026 come aggiornamento di manutenzione con quattro elementi di rafforzamento della sicurezza. Tre recano ID CVE: CVE-2026-84790 (byte NULL nei subject dei certificati), CVE-2026-88964 (underflow unsigned nella gestione di domain-search / PUSH_REPLY su Windows e Android per le versioni da 2.7_alpha3 a 2.7.7) e CVE-2026-84256 (ulteriore rafforzamento del quoting di CreateProcess/cmd.exe su Windows). Una quarta modifica a tls-crypt-v2 che impedisce ai client di rinviare alla cieca chiavi wrappate quando non è disponibile materiale di chiave è stata lasciata senza CVE nell'ambito della policy di robustness CRA dell'Italia. Il rilascio migliora anche la stabilità DCO multi-client, incluso il riavvio di una singola istanza invece di far crashare l'intero server quando l'installazione della chiave di un peer entra in race con la rimozione del peer. Linux Compatible rileva che il rilascio è stato taggato da Gert Doering dopo circa 22 commit su 40 file da 11 contributori, sulla scia della revisione architetturale 2.7.0 di febbraio. Gli operatori che gestiscono server multi-client o DCO accelerato a livello kernel dovrebbero trattare la 2.7.8 come un rilascio di manutenzione per disponibilità e sicurezza, non come un drop di funzionalità. I team di tooling dei certificati devono inventariare le stringhe subject per byte NULL incorporati prima dell'upgrade delle flotte OpenSSL, perché i certificati precedentemente accettati potrebbero improvvisamente fallire i controlli di handshake. Gli amministratori Windows dovrebbero eseguire regression test degli script che effettuano shell-out tramite CreateProcess intorno a OpenVPN dopo l'ulteriore rafforzamento del quoting.

Se si eseguono client OpenVPN community 2.7.x su Windows/Android o server DCO multi-client, pianificare la 2.7.8 e ritestare gli inventari dei certificati per byte NULL incorporati. Registrare le versioni dei pacchetti e gli URL degli advisory nel ticket di change prima di chiudere la voce.

Fonte: Linux Compatible

La pagina CVE-2026-88964 della wiki della community OpenVPN afferma che un integer underflow consente a server remoti autenticati di causare denial of service o disclosure di memoria tramite opzioni domain search appositamente confezionate, indica Cole Munz come reporter, collega la issue privata GitHub OpenVPN/openvpn-private-issues#178 e indirizza gli operatori alla voce ReleaseHistory di openvpn-2.7.8 datata 7 ottobre 2026. La wiki collega anche l'anchor ReleaseHistory della community per openvpn-2.7.8 rilasciato il 7 ottobre 2026 e il percorso della issue privata GitHub usato durante la disclosure coordinata. I lettori dovrebbero trattare i domini di ricerca DNS PUSH_REPLY come materiale di opzione sensibile: solo i server attendibili dovrebbero essere autorizzati a effettuare il push, e le schermate About del client dovrebbero essere acquisite dopo l'upgrade per dimostrare che è in esecuzione la 2.7.8 o successiva sugli endpoint Windows e Android nella finestra 2.7.x precedentemente interessata.

Trattare le opzioni di ricerca DNS PUSH_REPLY solo da server attendibili e confermare che le schermate About del client mostrino 2.7.8+ dopo l'upgrade. Registrare le versioni dei pacchetti e gli URL degli advisory nel ticket di change prima di chiudere la voce.

Fonte: wiki della community OpenVPN

Sicurezza Internet

Il 5 ottobre 2026, una discussione sulla Linux kernel mailing list relativa a una patch noise di WireGuard ha descritto una modalità di fallimento in cui WireGuard può accettare una risposta di handshake vecchia dopo che è stata avviata un'initiation più recente, reinstallando chiavi vecchie e azzerando i contatori di trasporto e lo stato di replay. Ciò consentirebbe il riutilizzo dei nonce, il replay e la contraffazione dei pacchetti, compromettendo le garanzie di riservatezza e integrità. La correzione proposta confronta i secret effimeri sotto il write lock per rifiutare le risposte relative a initiation sostituite; Jason A. Donenfeld ha messo in discussione il flusso esatto in una risposta sullo stesso thread. Il thread sottolinea che accettare una risposta di handshake stale dopo che è iniziata un'initiation più recente può reinstallare chiavi più vecchie e azzerare lo stato di replay. Si tratta di un problema di riservatezza e integrità per i peer WireGuard in-kernel, distinto dalle app VPN userspace di marca. Le distribuzioni andrebbero monitorate per i backport stable; non presupporre che una patch della mailing list sia già presente in ogni pacchetto kernel eseguito dalla flotta.

I consumatori WireGuard a livello kernel e di distribuzione dovrebbero monitorare i backport stable delle patch di rifiuto delle risposte di handshake ed evitare di presupporre che le sole app VPN userspace coprano i peer WireGuard in-kernel. Registrare le versioni dei pacchetti e gli URL degli advisory nel ticket di change prima di chiudere la voce.

Fonte: LKML / IU archive

Il record NVD per CVE-2026-13735 descrive un bug nell'implementazione WireGuard di Zephyr RTOS: i messaggi keepalive (plaintext vuoto di 16 byte più tag Poly1305) venivano accettati prima della decrittazione, quindi il tag Poly1305 non veniva mai verificato. Un attaccante che conosceva o otteneva tramite brute-force un receiver index in chiaro poteva falsificare i segnali di stato keepalive senza le chiavi di sessione. La correzione obbliga i payload di 16 byte a passare attraverso la decrittazione e i controlli anti-replay. L'impatto è limitato all'integrità dei segnali di stato, non all'iniezione di plaintext o al takeover della sessione. La descrizione NVD chiarisce che i keepalive contraffatti, dopo la correzione, falliscono la verifica Poly1305 e vengono conteggiati come errori di autenticazione. Nel percorso precedente alla correzione non viene decrittato né iniettato alcun plaintext, e gli endpoint e i timer di liveness non venivano aggiornati dal return anticipato, quindi l'iniezione di traffico e il takeover della sessione esulano dall'ambito di questo specifico difetto. I team di sicurezza dei prodotti dovrebbero comunque applicare la patch, perché i segnali VPN-connected contraffatti possono fuorviare i management plane e gli operatori.

I prodotti Embedded/IoT che includono Zephyr WireGuard dovrebbero recepire la correzione authenticated-keepalive e non equiparare questa CVE a WireGuard del kernel Linux. Registrare le versioni dei pacchetti e gli URL degli advisory nel ticket di change prima di chiudere la voce.

Fonte: NVD — CVE-2026-13735

Regolamentazione

Il resoconto di Linux Compatible sulla 2.7.8 osserva che le linee guida della Computer Resilience Agency (CRA) italiana sono state citate come motivo per cui una correzione dell'interruzione del client tls-crypt-v2 non ha ricevuto un CVE: un server malevolo che impedisce a un client di funzionare correttamente è stato classificato come degrado della robustezza anziché come un fallimento di riservatezza o integrità. Tale scelta di policy non elimina la necessità operativa di applicare la patch, ma cambia il modo in cui i sistemi di ticketing di conformità possono etichettare la modifica. I programmi di sicurezza che aprono ticket solo quando esiste un ID CVE perderanno questa classe di modifiche, a meno che la revisione delle note di rilascio non faccia parte del processo di intake. Documentare la motivazione della CRA nel corpo del ticket e richiedere comunque la verifica in staging per i client tls-crypt-v2 dopo la 2.7.8, perché i fallimenti di disponibilità verso peer autenticati restano costosi durante la risposta agli incidenti.

I programmi di sicurezza dovrebbero tracciare le correzioni di robustezza senza CVE nei client VPN quando le policy in stile CRA omettono gli identificatori. Registrare le versioni dei pacchetti e gli URL degli advisory nel ticket di change prima di chiudere l'elemento.

Fonte: Linux Compatible

Forum

La voce pubblica del wiki CVE di OpenVPN per 88964 collega il percorso del tracker di issue privato di GitHub OpenVPN/openvpn-private-issues#178 e l'ancora comunitaria ReleaseHistory per la 2.7.8, illustrando la prassi del progetto di pubblicare i nomi dei reporter e i numeri delle issue private insieme alle note di rilascio anziché patch silenziose. Partire dalle pagine di annuncio di sicurezza di proprietà del progetto riduce il rischio di inseguire sintesi secondarie incomplete. Verificare incrociando i nomi dei reporter, i riferimenti alle issue private e le ancore ReleaseHistory prima di chiudere i ticket di vulnerabilità come mitigati.

Nel triage dei CVE VPN, partire dal wiki di annuncio di sicurezza del progetto stesso e dalle ancore ReleaseHistory prima degli aggregatori secondari. Registrare le versioni dei pacchetti e gli URL degli advisory nel ticket di change prima di chiudere l'elemento.

Fonte: wiki della community OpenVPN

Fornitori

Linux Compatible riporta che il team Access Server di OpenVPN Inc. ha segnalato il bug di race su iroute corretto nella 2.7.8, in cui le route per-client venivano rimosse durante la pulizia ritardata multi-istanza anziché al momento effettivo di uscita del client, con il rischio di sistemi rimasti senza route in condizioni di race di riconnessione. Lo stesso articolo nota che gruppi di ricerca esterni come BreachX (segnalazione del NULL-byte nei certificati) alimentano la cadenza di sicurezza della 2.7.x. Lo staging dovrebbe includere tempeste di riconnessione che esercitano l'installazione e la rimozione delle route mentre i client flappano. Se le route scompaiono sotto carico dopo l'upgrade, catturare i log netlink e di istanza prima di procedere oltre. Il coinvolgimento di BreachX nella segnalazione del NULL-byte nei certificati illustra anche perché le pipeline di ricerca esterne contano per la cadenza 2.7.x di OpenVPN.

Access Server e i grandi operatori DCO dovrebbero convalidare il comportamento di pulizia delle route in staging dopo la 2.7.8 prima delle ondate di produzione. Registrare le versioni dei pacchetti e gli URL degli advisory nel ticket di change prima di chiudere l'elemento.

Fonte: Linux Compatible