# Failles OpenVPN - sécuriser les accès distants de votre infrastructure Linux

> Failles OpenVPN : versions corrigées sur Ubuntu, accès de secours et tests après maintenance pour sécuriser les accès distants de votre infrastructure Linux.

- URL canonique : [https://forgetaboutit.fr/blog/failles-openvpn-securiser-acces-distants-linux/](https://forgetaboutit.fr/blog/failles-openvpn-securiser-acces-distants-linux/)
- Publication : 2026-10-03T07:10:00.000Z
- Catégorie : Sécurité
- Sujets : OpenVPN, Linux, CVE, Patch management, Infogérance

**Les failles OpenVPN CVE-2026-84471 et CVE-2026-84732 font l'objet de correctifs Ubuntu publiés le 30 septembre 2026.** Le bulletin concerne les versions 22.04, 24.04 et 26.04 LTS. Cette date est celle de la mise à disposition des correctifs Ubuntu, pas celle de la découverte des vulnérabilités. [Bulletin Canonical USN-8852-1](https://ubuntu.com/security/notices/USN-8852-1).

Pour une équipe qui administre ses serveurs à travers ce VPN, le sujet dépasse l'installation d'un paquet. **Il faut corriger le point d'entrée sans perdre le moyen d'intervenir sur l'infrastructure.** Inventaire, accès de secours, redémarrage et validation des connexions font partie de la même opération.

## Deux failles OpenVPN à qualifier sur votre parc

### CVE-2026-84471 - un défaut de gestion mémoire des sessions TLS

OpenVPN décrit une possible double libération d'un tampon de session TLS, liée à une protection incomplète dans le code. L'avis amont cite les branches 2.6.0 à 2.6.22 et 2.7_alpha1 à 2.7.6 ; il indique une correction dans les versions 2.6.23 et 2.7.7. [Avis de sécurité OpenVPN](https://community.openvpn.net/Security%20Announcements/CVE-2026-84471).

Canonical évoque un plantage du service et une exécution de code potentielle. Cela justifie la correction, sans présenter pour autant toute installation comme une prise de contrôle distante sans authentification. [Détails du bulletin Ubuntu](https://ubuntu.com/security/notices/USN-8852-1).

### CVE-2026-84732 - un risque de déni de service dans les retransmissions

La seconde faille concerne les acquittements, ces messages qui confirment la réception de paquets. Des entrées spécialement construites peuvent provoquer un débordement d'entier dans le calcul d'un délai et perturber le service. La fiche Canonical décrit un déni de service distant sans authentification sur les versions amont allant jusqu'à 2.6.22 et 2.7.6. [Fiche CVE-2026-84732](https://ubuntu.com/security/CVE-2026-84732).

Les notes de version confirment les corrections dans [OpenVPN 2.6.23](https://github.com/OpenVPN/openvpn/releases/tag/v2.6.23) et [OpenVPN 2.7.7](https://github.com/OpenVPN/openvpn/releases/tag/v2.7.7).

Notre recommandation est de partir du logiciel réellement déployé : version, origine du paquet, rôle client ou serveur, interfaces accessibles et configuration. Un nom de produit dans un inventaire ne suffit pas à établir l'exposition. Les versions ci-dessous concernent le paquet Ubuntu `openvpn` ; elles ne sont pas une consigne de mise à niveau universelle pour les appliances, les autres distributions ou OpenVPN Access Server.

## Quelles versions installer sur Ubuntu ?

Le bulletin fournit les révisions corrigées suivantes :

| Version Ubuntu | Paquet `openvpn` corrigé |
| --- | --- |
| 22.04 LTS | `2.5.11-0ubuntu0.22.04.5` |
| 24.04 LTS | `2.6.19-0ubuntu0.24.04.4` |
| 26.04 LTS | `2.7.0-1ubuntu1.3` |

Source : [versions publiées par Canonical](https://ubuntu.com/security/notices/USN-8852-1).

**Une version amont apparemment ancienne peut donc être corrigée par la distribution.** Il faut comparer la révision complète du paquet au bulletin de votre système, plutôt que conclure à partir du seul numéro affiché par le binaire. Une version ultérieure du même dépôt maintenu peut naturellement intégrer ces correctifs.

Sur une installation utilisant les paquets Ubuntu, ces commandes permettent de relever la version installée et les versions proposées par les dépôts configurés :

```bash
dpkg-query -W -f='${Package} ${Version}\n' openvpn
apt-cache policy openvpn
```

Pour un VPN conteneurisé, ce contrôle doit porter sur l'image et le processus qui assurent réellement le tunnel. Mettre à jour l'hôte ne remplace pas la reconstruction ou le remplacement d'une image qui embarque encore un composant vulnérable.

## Préparer la maintenance sans perdre les accès d'administration

Le premier contrôle est concret : **comment reprendre la main si le tunnel ne remonte pas ?** Une console chez l'hébergeur, un accès hors bande ou un second chemin d'administration doivent être disponibles et testés avant l'intervention. Une deuxième session SSH passant par le même VPN n'est pas un accès indépendant.

Nous recommandons de préparer quatre éléments :

1. **Le périmètre.** Identifier les instances VPN, les utilisateurs, les interconnexions de sites et les services qui en dépendent. La supervision et les sauvegardes peuvent elles aussi emprunter ce chemin.
2. **La configuration de reprise.** Conserver les paramètres, les règles réseau, les scripts associés et les éléments d'authentification nécessaires dans un stockage protégé, accessible sans le VPN à réparer.
3. **Le créneau d'intervention.** Prévenir les utilisateurs et prévoir les reconnexions. Sur une architecture redondée, vérifier la bascule avant de traiter les instances successivement.
4. **Les critères de validation.** Définir à l'avance les connexions et les services à tester, ainsi que la personne qui peut décider d'une reprise ou d'une correction complémentaire.

Cette préparation rejoint notre démarche de [cartographie des dépendances avant une reprise d'infogérance](/blog/cartographier-dependances-prealable-infogerance/). Elle permet de savoir ce qu'une interruption du VPN affectera réellement, au lieu de le découvrir pendant la maintenance.

## Appliquer le correctif et vérifier le service réellement exécuté

Pour une installation Ubuntu gérée par APT, la mise à jour ciblée peut s'effectuer ainsi, **une fois l'accès de secours opérationnel et la maintenance préparée**. L'installation d'un paquet peut elle-même provoquer un redémarrage de service selon la configuration du système : il ne faut pas attendre la commande de redémarrage manuelle pour anticiper la coupure.

```bash
sudo apt update
sudo apt install --only-upgrade openvpn
```

Relire ensuite la version installée et vérifier qu'elle correspond au correctif attendu. Si le dépôt ne propose pas la bonne révision, il faut comprendre pourquoi : miroir en retard, paquet bloqué, dépôt tiers ou version du système non couverte.

**Canonical demande de redémarrer OpenVPN après la mise à jour.** Le paquet corrigé sur disque ne suffit pas si une ancienne instance reste en mémoire. [Instructions du bulletin USN-8852-1](https://ubuntu.com/security/notices/USN-8852-1).

Le nom du service dépend du déploiement. Avec systemd, commencer par identifier les unités concernées :

```bash
systemctl list-units --all 'openvpn*'
```

Redémarrer ensuite les instances identifiées dans le cadre de la procédure prévue. Nous évitons ici une commande générique qui pourrait viser la mauvaise unité ou couper plusieurs tunnels à la fois.

## Un VPN démarré n'est pas encore un accès validé

La validation doit partir d'une **nouvelle connexion depuis l'extérieur**, avec un profil représentatif. Un processus actif ou un port accessible ne prouvent pas que les utilisateurs peuvent travailler.

Nous vérifierions notamment :

- l'authentification et l'établissement du tunnel ;
- la résolution DNS et les routes vers les réseaux attendus ;
- l'accès aux interfaces d'administration ou applications utiles ;
- le maintien des restrictions vers les réseaux non autorisés ;
- les reconnexions et l'absence d'erreurs inhabituelles dans les journaux.

Pour une liaison entre sites, les contrôles doivent couvrir les échanges dans les deux sens. La supervision doit ensuite confirmer le retour à un fonctionnement stable. C'est la différence entre [surveiller un processus et superviser un service utile](/blog/supervision-monitoring-outils-infrastructure-saine/).

## L'infogérance relie la veille de sécurité à la continuité des accès

Un bulletin n'apporte de protection que lorsqu'il est rapproché du parc, traité et suivi d'une vérification. C'est pourquoi le [suivi quotidien des CVE](/blog/suivi-cve-pourquoi-quotidien/) doit déboucher sur une décision d'exploitation : quels systèmes corriger, dans quel ordre et avec quel moyen de reprise ?

Chez Forget About IT, notre approche de l'[infogérance de serveurs Linux](/infogerance/) associe précisément cette veille à la maintenance, à la supervision et aux procédures d'intervention. Le VPN fait partie du périmètre technique à connaître et à maintenir, au même titre que les services auxquels il donne accès.

L'objectif est simple : **réduire l'exposition tout en conservant la capacité d'administrer l'infrastructure.** Vous souhaitez faire le point sur vos accès distants et leur maintenance ? [Échangeons sur votre environnement](/contact/).

## FAQ - mises à jour de sécurité OpenVPN

### Quelles failles OpenVPN sont corrigées par le bulletin USN-8852-1 ?

Le bulletin concerne CVE-2026-84471, un défaut de gestion mémoire des sessions TLS, et CVE-2026-84732, un défaut de retransmission des acquittements pouvant provoquer un déni de service. Il fournit des correctifs pour Ubuntu 22.04, 24.04 et 26.04 LTS.

### Faut-il installer une nouvelle version majeure d'OpenVPN sur Ubuntu ?

Pas nécessairement. Canonical fournit des paquets corrigés pour chaque version Ubuntu couverte par le bulletin. Il faut vérifier la révision complète du paquet, pas seulement le numéro de version amont.

### Faut-il redémarrer OpenVPN après la mise à jour ?

Oui, le bulletin Canonical demande un redémarrage d'OpenVPN. Il faut préparer un accès de secours indépendant du tunnel, puis vérifier une nouvelle connexion et l'accès aux services internes.