La version de maintenance 2.7.8 d’OpenVPN (discussion publique datée du 7 October 2026) regroupe trois correctifs étiquetés CVE plus un changement de robustesse de tls-crypt-v2 qui ne porte délibérément aucun ID CVE. Cette note de sécurité relie les avis principaux afin que les opérateurs puissent prioriser les clients Windows et Android, les outils de certificats et les serveurs DCO multi-clients sans traiter les blogs marketing comme unique source de vérité.

Encrypt-then-MAC authenticated encryption construction diagram
Source : Wikimedia Commons (RokerHRO) — Chiffrement authentifié EtM

Sources primaires

CVE-2026-88964 — sous-dépassement de domain search

Le wiki communautaire indique qu'un sous-dépassement d'entier dans OpenVPN sous Windows et Android permet à des serveurs distants authentifiés de provoquer un déni de service ou une divulgation de mémoire via des options domain search conçues à dessein dans le traitement de PUSH_REPLY. Il s'agit d'une classe de bogues classique « pair de confiance, options hostiles » : l'authentification a déjà réussi, mais l'analyse des options faisait encore trop confiance à l'arithmétique des longueurs. L'impact est un déni de service et une divulgation de mémoire potentielle, et non une affirmation d'exécution de code à distance sans contrainte dans le texte public du wiki. Le correctif est livré dans 2.7.8.

Les défenseurs doivent partir du principe que tout client encore en 2.7.7 ou antérieur dans la fenêtre concernée reste exposé lorsqu'il se connecte à un point de terminaison hostile mais authentifié, y compris des concentrateurs d'entreprise compromis et des serveurs de laboratoire mal contrôlés. La condition préalable est facile à mal comprendre : il ne s'agit pas d'un inconnu non authentifié qui asperge un client aléatoire de paquets. Il faut que le client fasse déjà suffisamment confiance au pair pour terminer l'authentification et accepter les options PUSH_REPLY. Les concentrateurs compromis, les laboratoires de test malveillants et les profils mal émis restent des voies réalistes. Il ne faut pas amplifier l'avis en un récit d'exécution de code à distance non authentifiée que le wiki OpenVPN ne revendique pas.

CVE-2026-84790 — octets NULL dans les sujets de certificat

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

Linux Compatible indique que les certificats contenant des octets NULL intégrés dans les chaînes de sujet sont désormais refusés. Les builds OpenSSL risquaient auparavant que les analyseurs s’arrêtent au premier octet NULL ; les builds mbedTLS rejetaient déjà de tels certificats. Vivek Parikh de BreachX a signalé le problème ; Max Fillinger a implémenté le correctif. Impact opérationnel : les certificats archivés ou conçus de façon malveillante qui « fonctionnaient » autrefois sur OpenSSL peuvent échouer après la mise à niveau. Les équipes d’outillage des certificats devraient scanner les inventaires avant un déploiement de masse et traiter les échecs soudains de handshake après 2.7.8 comme un signal d’hygiène des certificats plutôt que comme un simple accroc réseau.

Ce refus peut également casser les outils hérités qui intégraient accidentellement des caractères NUL lors de la génération des chaînes de sujet. Cette casse est souhaitable du point de vue de la sécurité des analyseurs, mais les fenêtres de changement nécessitent une étape d’inventaire. Associez la mise à niveau OpenVPN à des revues du texte des certificats ou à des rapports PKI d’entreprise qui signalent les octets non imprimables dans les sujets avant de déclarer le déploiement terminé.

CVE-2026-84256 — Quoting Windows CreateProcess

La version 2.7.8 poursuit le durcissement autour du quoting de la ligne de commande Windows afin que les caractères spéciaux pour cmd.exe ne puissent pas déclencher d’expansion de variables à l’intérieur d’arguments entre guillemets. Lev Stipakov a implémenté le travail ; Darren Carreras l’a signalé. Le même numéro CVE a été partiellement traité dans 2.7.7, si bien que 2.7.8 est un second passage sur le même chemin plutôt qu’un bogue Windows sans rapport. Les scripts qui invoquent un shell autour d’OpenVPN sous Windows méritent des tests de régression après la mise à niveau, surtout lorsqu’ils transmettent des chemins de profil contrôlés par l’utilisateur ou des arguments d’aide via CreateProcess.

Robustesse de tls-crypt-v2 sans CVE

Lors des handshakes tls-crypt-v2, OpenVPN pouvait tenter d’ajouter une clé client encapsulée même lorsqu’aucun matériel de clé n’était disponible, faisant trop confiance à une demande de renvoi d’un pair. Le changement de 2.7.8 met fin à cette confiance aveugle. Selon les orientations de l’Agence italienne de résilience informatique telles que relayées par Linux Compatible, « un serveur malveillant peut empêcher le client de fonctionner correctement » a été traité comme une dégradation de robustesse plutôt que comme un CVE de confidentialité ou d’intégrité. Les opérateurs devraient tout de même l’installer : les attaques de disponibilité contre les clients VPN sont opérationnellement coûteuses même lorsqu’elles n’ont pas l’apparat d’un CVE, et les systèmes de gestion du changement devraient suivre explicitement le durcissement hors CVE.

L’identifiant manquant illustre une leçon plus large pour les programmes de sécurité VPN. Les politiques qui omettent les identifiants CVE pour les seuls problèmes de disponibilité contre des pairs déjà authentifiés masqueront une partie de 2.7.8 à moins que les opérateurs n’enregistrent des éléments de robustesse explicites. L’article du 7 octobre 2026 de Linux Compatible constitue un contexte secondaire utile, mais les tickets de changement devraient toujours renvoyer vers les pages OpenVPN ReleaseHistory et wiki CVE comme preuves primaires.

Travaux de disponibilité connexes que les opérateurs ne doivent pas ignorer

Au-delà de la liste des CVE, 2.7.8 modifie le comportement multi-client et de déchargement du canal de données. Les routes par client sont retirées au moment réel de la sortie plutôt que lors du nettoyage différé multi-instance, corrigeant une condition de course qui pouvait laisser les systèmes sans aucune route. Un socket netlink dédié sépare le travail synchrone des notifications asynchrones. Lorsqu’une opération sur un pair ou une clé échoue après que le pair a déjà disparu du noyau, OpenVPN redémarre une seule instance au lieu de tuer l’ensemble du serveur. Ces correctifs de disponibilité et de justesse comptent autant que les CVE pour les grands serveurs soumis à des tempêtes de reconnexion, et ils ont été signalés en partie par l’équipe Access Server d’OpenVPN Inc. selon Linux Compatible.

Ce que ce n’est pas

  • Ce n’est pas un avis WireGuard. Les discussions WireGuard distinctes d’octobre 2026, y compris les correctifs LKML de réponse de handshake et le CVE-2026-13735 d’authentification keepalive Zephyr, appartiennent à leurs propres notes.
  • Pas du marketing de notes de version d’un fournisseur pour une marque VPN commerciale grand public.
  • Pas une autorisation d’exécuter des serveurs non fiables « pour tester » la classe de bugs des serveurs authentifiés.

Octobre 2026 a également vu des discussions liées à WireGuard que les opérateurs peuvent confondre avec des correctifs OpenVPN. Le fil handshake-response du LKML et le problème de keepalive Zephyr CVE-2026-13735 du NVD sont réels, mais ils ne corrigent pas OpenVPN 2.7.8, et OpenVPN 2.7.8 ne les remédie pas. Conservez des inventaires séparés par binaire : OpenVPN communautaire, WireGuard in-kernel, WireGuard en espace utilisateur, piles Zephyr et applications VPN mobiles propriétaires. Mélanger ces lignées dans une seule feuille de calcul « VPN CVE » est ainsi que les équipes manquent les clients OpenVPN Windows et Android que CVE-2026-88964 nomme réellement.

Liste de contrôle du défenseur

  1. Inventoriez les clients OpenVPN Windows et Android dans la fenêtre 2.7.x et déployez la 2.7.8 ou une version plus récente.
  2. Analysez les magasins de certificats à la recherche d’octets NULL intégrés avant la mise à niveau des flottes OpenSSL.
  3. Répétez les redémarrages DCO et multi-clients sur un nœud de préproduction pour absorber les changements de comportement au redémarrage d’instance.
  4. Maintenez les déploiements tls-crypt-v2 sur des builds corrigés même lorsqu’un correctif n’a pas d’identifiant CVE.
  5. Citez les avis primaires dans les tickets de changement plutôt que les blogs secondaires uniquement.
  6. Séparez les tickets clients OpenVPN des tickets kernel WireGuard et Zephyr.

En résumé : traitez OpenVPN 2.7.8 comme un ensemble de sécurité et de disponibilité pour l’analyse du canal de contrôle, l’hygiène des certificats, le quoting des processus Windows et la stabilité du déchargement du canal de données des grands serveurs. Vérifiez ensuite avec vos propres hachages de paquets et laboratoires de préproduction avant de déclarer le cluster CVE clos.