Technologie VPN

OpenVPN 2.7.8 a été publié autour des 6–7 octobre 2026 comme une mise à jour de maintenance comportant quatre éléments de durcissement de la sécurité. Trois portent des identifiants CVE : CVE-2026-84790 (octets NULL dans les sujets de certificats), CVE-2026-88964 (sous-dépassement non signé dans le traitement domain-search / PUSH_REPLY sous Windows et Android pour les versions 2.7_alpha3 à 2.7.7), et CVE-2026-84256 (poursuite du durcissement du quoting CreateProcess/cmd.exe sous Windows). Un quatrième changement tls-crypt-v2, qui empêche les clients de renvoyer aveuglément des clés encapsulées lorsqu'aucun matériel de clé n'est disponible, a été laissé sans CVE conformément à la politique de robustesse CRA de l'Italie. La version améliore également la stabilité DCO multi-clients, notamment en redémarrant une seule instance au lieu de faire planter tout le serveur lorsqu'une installation de clé de pair entre en course avec la suppression du pair. Linux Compatible indique que la version a été étiquetée par Gert Doering après environ 22 commits sur 40 fichiers provenant de 11 contributeurs, s'appuyant sur la refonte architecturale 2.7.0 de février. Les opérateurs qui font tourner des serveurs multi-clients ou du DCO accéléré par le noyau doivent traiter 2.7.8 comme une version de maintenance de disponibilité et de sécurité plutôt que comme une livraison de fonctionnalités. Les équipes d'outillage des certificats doivent inventorier les chaînes de sujet à la recherche d'octets NULL embarqués avant la mise à niveau des parcs OpenSSL, car des certificats auparavant acceptés peuvent soudainement échouer aux contrôles de handshake. Les administrateurs Windows doivent tester en régression les scripts qui invoquent CreateProcess autour d'OpenVPN après le durcissement continu du quoting.

Si vous exécutez des clients OpenVPN communautaires 2.7.x sous Windows/Android ou des serveurs DCO multi-clients, planifiez 2.7.8 et retestez les inventaires de certificats à la recherche d'octets NULL embarqués. Enregistrez les versions des paquets et les URL des avis dans le ticket de changement avant de clore l'élément.

Source : Linux Compatible

La page CVE-2026-88964 du wiki communautaire OpenVPN indique qu'un sous-dépassement d'entier permet à des serveurs distants authentifiés de provoquer un déni de service ou une divulgation de mémoire via des options de recherche de domaine conçues à dessein, nomme Cole Munz comme rapporteur, lie le ticket GitHub privé OpenVPN/openvpn-private-issues#178, et oriente les opérateurs vers l'entrée ReleaseHistory openvpn-2.7.8 datée du 7 octobre 2026. Le wiki lie également l'ancre ReleaseHistory communautaire pour openvpn-2.7.8 publié le 7 octobre 2026 et le chemin du ticket GitHub privé utilisé pendant la divulgation coordonnée. Les lecteurs doivent traiter les domaines de recherche DNS PUSH_REPLY comme du matériel d'option sensible : seuls les serveurs de confiance doivent être autorisés à les pousser, et les écrans À propos des clients doivent être capturés après la mise à niveau pour prouver que 2.7.8 ou une version plus récente s'exécute sur les points de terminaison Windows et Android dans la fenêtre 2.7.x précédemment affectée.

N'acceptez les options de recherche DNS PUSH_REPLY que de serveurs de confiance et confirmez que les écrans À propos des clients affichent 2.7.8+ après la mise à niveau. Enregistrez les versions des paquets et les URL des avis dans le ticket de changement avant de clore l'élément.

Source : Wiki communautaire OpenVPN

Sécurité Internet

Le 5 octobre 2026, une discussion sur la liste de diffusion du noyau Linux à propos d'un correctif noise WireGuard a décrit un mode de défaillance où WireGuard peut accepter une ancienne réponse de handshake après qu'une initiation plus récente a commencé, réinstallant d'anciennes clés et réinitialisant les compteurs de transport et l'état de rejeu. Cela permettrait la réutilisation de nonce, le rejeu et la falsification de paquets, brisant les garanties de confidentialité et d'intégrité. Le correctif proposé compare les secrets éphémères sous le verrou d'écriture afin de rejeter les réponses pour les initiations remplacées ; Jason A. Donenfeld a contesté le flux exact dans une réponse sur le même fil. Le fil souligne que l'acceptation d'une réponse de handshake obsolète après le début d'une initiation plus récente peut réinstaller d'anciennes clés et réinitialiser l'état de rejeu. Il s'agit d'un enjeu de confidentialité et d'intégrité pour les pairs WireGuard dans le noyau, distinct des applications VPN de marque en espace utilisateur. Les distributions doivent être surveillées pour les rétroportages stables ; ne supposez pas qu'un correctif de liste de diffusion soit déjà présent dans chaque paquet noyau de votre parc.

Les consommateurs WireGuard du noyau et des distributions doivent surveiller les rétroportages stables des correctifs de rejet des réponses de handshake et éviter de supposer que les applications VPN en espace utilisateur couvrent à elles seules les pairs WireGuard dans le noyau. Enregistrez les versions des paquets et les URL des avis dans le ticket de changement avant de clore l'élément.

Source : LKML / IU archive

L’enregistrement NVD pour CVE-2026-13735 décrit un bogue d’implémentation WireGuard de Zephyr RTOS : les messages keepalive (texte en clair vide de 16 octets plus une étiquette Poly1305) étaient acceptés avant le déchiffrement, de sorte que l’étiquette Poly1305 n’était jamais vérifiée. Un attaquant qui connaissait ou obtenait par force brute un index de récepteur en clair pouvait usurper les signaux d’état keepalive sans clés de session. Le correctif force les charges utiles de 16 octets à passer par le déchiffrement et les contrôles anti-rejeu. L’impact se limite à l’intégrité des signaux d’état, et non à l’injection de texte en clair ni à la prise de contrôle de session. La description NVD précise qu’après le correctif, les keepalives falsifiés échouent à la vérification Poly1305 et sont comptabilisés comme des échecs d’authentification. Aucun texte en clair n’est déchiffré ni injecté dans le chemin antérieur au correctif, et les points de terminaison ainsi que les minuteries de présence n’étaient pas mis à jour par le retour anticipé, de sorte que l’injection de trafic et la prise de contrôle de session sont hors du périmètre de ce défaut particulier. Les équipes de sécurité produit doivent néanmoins appliquer le correctif, car des signaux usurpés indiquant une connexion VPN peuvent induire en erreur les plans de gestion et les opérateurs.

Les produits embarqués/IoT livrés avec Zephyr WireGuard doivent intégrer le correctif de keepalive authentifié et ne pas assimiler cette CVE à WireGuard du noyau Linux. Enregistrez les versions des paquets et les URL des avis de sécurité dans le ticket de changement avant de clôturer l’élément.

Source : NVD — CVE-2026-13735

Réglementation

L’article de Linux Compatible sur la 2.7.8 indique que les lignes directrices de l’Agence italienne de résilience informatique (CRA) ont été citées comme motif pour lequel un correctif de perturbation client tls-crypt-v2 n’a pas reçu de CVE : un serveur malveillant empêchant un client de fonctionner correctement a été classé comme une dégradation de la robustesse plutôt que comme une défaillance de confidentialité ou d’intégrité. Ce choix de politique n’élimine pas le besoin opérationnel d’appliquer le correctif, mais il modifie la façon dont les systèmes de tickets de conformité peuvent étiqueter le changement. Les programmes de sécurité qui n’ouvrent des tickets que lorsqu’un identifiant CVE existe manqueront cette classe de changement, sauf si l’examen des notes de version fait partie du processus d’admission. Documentez la justification CRA dans le corps du ticket et exigez tout de même une vérification en préproduction pour les clients tls-crypt-v2 après 2.7.8, car les défaillances de disponibilité face à des pairs authentifiés restent coûteuses pendant la réponse aux incidents.

Les programmes de sécurité devraient suivre les correctifs de robustesse sans CVE dans les clients VPN lorsque des politiques de type CRA omettent les identifiants. Enregistrez les versions des paquets et les URL des avis dans le ticket de changement avant de clôturer l’élément.

Source : Linux Compatible

Forums

L’entrée wiki CVE publique d’OpenVPN pour 88964 établit un lien croisé vers le chemin du tracker d’issues GitHub privé OpenVPN/openvpn-private-issues#178 et l’ancre communautaire ReleaseHistory pour 2.7.8, illustrant la pratique du projet de publier les noms des rapporteurs et les numéros d’issues privées aux côtés des notes de version plutôt que des correctifs silencieux. Partir des pages d’annonces de sécurité appartenant au projet réduit le risque de poursuivre des synthèses secondaires incomplètes. Recoupez les noms des rapporteurs, les références d’issues privées et les ancres ReleaseHistory avant de clôturer les tickets de vulnérabilité comme atténués.

Lors du triage des CVE VPN, partez du wiki d’annonces de sécurité du projet lui-même et des ancres ReleaseHistory avant les agrégateurs secondaires. Enregistrez les versions des paquets et les URL des avis dans le ticket de changement avant de clôturer l’élément.

Source : Wiki communautaire OpenVPN

Fournisseurs

Linux Compatible rapporte que l’équipe Access Server d’OpenVPN Inc. a signalé le bug de course iroute corrigé dans 2.7.8, où les routes par client étaient retirées lors d’un nettoyage différé multi-instances plutôt qu’au moment réel de la sortie du client, risquant de laisser des systèmes sans routes lors de courses de reconnexion. Le même article note que des groupes de recherche externes tels que BreachX (rapport sur l’octet NULL des certificats) alimentent le rythme de sécurité de la série 2.7.x. La préproduction devrait inclure des tempêtes de reconnexion qui exercent l’installation et le retrait des routes pendant que les clients battent. Si les routes disparaissent sous charge après la mise à niveau, capturez les journaux netlink et d’instance avant de poursuivre le déploiement. L’implication de BreachX dans le rapport sur l’octet NULL des certificats illustre également pourquoi les pipelines de recherche externes comptent pour le rythme 2.7.x d’OpenVPN.

Les opérateurs Access Server et les grands opérateurs DCO devraient valider le comportement de nettoyage des routes en préproduction après 2.7.8 avant les vagues de production. Enregistrez les versions des paquets et les URL des avis dans le ticket de changement avant de clôturer l’élément.

Source : Linux Compatible