Ivanti encore. Fortinet encore. Palo Alto encore. Depuis 2019, les appliances VPN d'entreprise cumulent les vulnérabilités critiques exploitées en zero-day, et les groupes APT l'ont parfaitement intégré dans leur playbook opérationnel. Voici une analyse sans complaisance du problème structurel que représentent ces boîtiers pour votre sécurité périmétrique — et ce que vous pouvez concrètement faire pour réduire votre exposition.

Un bilan accablant : cinq ans de zero-days sur les mêmes produits

Pour comprendre l'ampleur du problème, il suffit de lire la chronologie. En août 2019, CVE-2019-11510 touche Pulse Secure (devenu depuis Ivanti Connect Secure) : une lecture arbitraire de fichiers sans authentification qui expose les credentials VPN de milliers d'organisations. La vulnérabilité est exploitée immédiatement par des groupes APT liés à des États, notamment pour cibler des entreprises de défense et des administrations américaines. Des mois après la publication du patch, la NSA et la CISA publient des alertes constatant que des milliers d'organisations n'ont toujours pas appliqué le correctif — et continuent d'être compromises.

En 2021, la même gamme Pulse/Ivanti est à nouveau frappée par CVE-2021-22893 (CVSS 10.0), cette fois un zero-day exploité avant même la publication d'un patch. En 2024, CVE-2024-21887 et CVE-2023-46805 forment une chaîne permettant l'exécution de code à distance et l'escalade de privilèges — de nouveau exploitées in-the-wild avant correction. Et en 2026, nous voici avec CVE-2026-104935, CVE-2026-111357 et CVE-2026-118527, enchaînées par l'acteur UTA0576 avec une sophistication croissante.

Ivanti n'est pas seul dans ce tableau. Fortinet a connu CVE-2022-42475 (CVSS 9.3, FortiOS SSL-VPN, exploitée par un acteur étatique), CVE-2024-21762 (CVSS 9.6, FortiOS, exploitation confirmée), et plusieurs autres entrées au catalogue KEV de la CISA. Palo Alto Networks a subi CVE-2024-3400 (CVSS 10.0, PAN-OS GlobalProtect, zero-day exploité avant patch disponible), l'une des vulnérabilités les plus critiques de 2024. Citrix NetScaler a été la cible de CVE-2023-3519 (CVSS 9.8, exploitée pour déployer des webshells dans des centaines d'organisations en quelques jours). Ces produits représentent ensemble la majorité du marché des accès distants sécurisés en entreprise.

Cette liste n'est pas exhaustive. Elle illustre un pattern systémique : les produits chargés d'assurer l'accès distant sécurisé des entreprises sont, de manière répétée, les vecteurs d'intrusion les plus productifs pour les adversaires étatiques et les groupes de ransomware. Ce n'est pas un accident — c'est la conséquence logique de caractéristiques structurelles de ces produits que nous allons examiner.

Pourquoi les appliances réseau sont structurellement vulnérables

La première caractéristique qui rend les appliances VPN attractives pour les attaquants est leur position réseau. Par définition, une appliance VPN d'accès distant est exposée directement sur Internet, généralement sur les ports 443 (HTTPS) ou 4433. Elle doit accepter des connexions de n'importe quelle source IP — c'est son rôle fonctionnel. Cette exposition maximale contraste avec la plupart des autres systèmes de l'entreprise, protégés derrière des firewalls, des bastions, ou accessibles uniquement depuis des plages d'adresses connues. L'appliance VPN est par construction le composant le plus exposé de votre infrastructure.

La deuxième caractéristique problématique est la complexité fonctionnelle de ces produits. Une appliance VPN d'entreprise moderne doit gérer des protocoles multiples (SSL/TLS, IPSec, SAML, RADIUS, LDAP/AD), analyser des flux HTTP complexes, exécuter du code serveur pour les portails web d'accès, intégrer des mécanismes d'authentification multifacteur, et souvent exécuter des agents tiers (antivirus, posture check du poste de travail). Cette complexité fonctionnelle est une surface d'attaque étendue, et chaque fonctionnalité est un vecteur d'exploitation potentiel. Plus un composant logiciel fait de choses complexes avec des entrées non fiables venant d'Internet, plus il contient statistiquement de vulnérabilités.

La troisième caractéristique est héritée de l'histoire : beaucoup de ces produits ont été développés dans les années 2000-2010, avec des bases de code C et C++ aujourd'hui vieillissantes. Ces langages offrent des performances élevées mais sont particulièrement exposés aux bugs mémoire (buffer overflows, use-after-free, format string bugs) si le code n'est pas développé avec une rigueur extrême. Certaines appliances tournent encore sur des systèmes d'exploitation embarqués basés sur des noyaux Linux très anciens, avec des protections mémoire moins robustes que les systèmes modernes. La complexité des parsers de protocoles (TLS, HTTP, SAML) représente une surface d'attaque particulièrement fertile.

La quatrième caractéristique est opérationnelle : les organisations hésitent à patcher leurs appliances VPN parce que le redémarrage peut couper l'accès distant de tous les collaborateurs en télétravail. Dans un environnement où 30 à 50% de la main-d'oeuvre travaille à distance, une coupure VPN pendant les heures ouvrées est perçue comme inacceptable par le métier. Cette pression opérationnelle ralentit l'application des patches et crée des fenêtres d'exposition prolongées, parfois de plusieurs semaines sur des CVE critiques. C'est exactement ce que les adversaires savent exploiter : ils weaponisent les exploits rapidement précisément parce qu'ils savent que les organisations mettront du temps à patcher.

Le playbook APT : comment ils opèrent en 2026

Les groupes APT sophistiqués disposent aujourd'hui d'équipes dédiées à la recherche de vulnérabilités dans les produits VPN et gateway d'entreprise. Leur processus est industrialisé : ils scannent en permanence via des outils spécialisés pour identifier les versions exposées sur Internet, maintiennent des inventaires de cibles prioritaires (secteur défense, énergie, santé, administration), et disposent de workflows permettant de weaponiser un exploit en quelques heures après la publication d'une CVE critique.

Le délai de weaponisation s'est drastiquement réduit ces cinq dernières années. En 2019-2020, les acteurs disposaient souvent d'une fenêtre de quelques semaines entre la publication d'une CVE et le début de l'exploitation massive. En 2024-2026, pour les CVE critiques dans des produits très exposés, ce délai se mesure en heures ou en jours pour les acteurs étatiques les plus avancés. Certains zero-days (CVE-2024-3400 de Palo Alto, CVE-2026-104935 d'Ivanti) sont exploités avant même que l'éditeur n'ait terminé d'investiguer le problème signalé par des chercheurs ou des victimes.

Une fois l'accès initial obtenu sur l'appliance VPN, les APT suivent un playbook bien documenté. Première étape : extraction des credentials des utilisateurs VPN en cours de session, y compris les tokens d'authentification forte dans certains cas. Deuxième étape : énumération du réseau interne via les routes configurées sur l'appliance, qui a une vision privilégiée de la topologie réseau. Troisième étape : implantation d'une backdoor persistante survivant aux redémarrages de l'appliance et à l'application des patches. Quatrième étape : déploiement d'un outillage de tunneling pour maintenir l'accès même si la vulnérabilité initiale est corrigée. L'objectif final varie selon l'acteur : espionnage persistant pour les APT étatiques, reconnaissance préalable à un ransomware pour les groupes cybercriminels.

Un élément tactique important : les APT modernes évitent de déclencher des alertes en utilisant des patterns de connexion mimant le trafic VPN légitime. Ils utilisent l'appliance compromise comme pivot, ce qui fait apparaître leur activité comme du trafic interne normal. Les outils de détection réseau traditionnels, qui inspectent les flux entre Internet et le périmètre, sont aveugles à cette phase de post-exploitation. C'est pourquoi la compromission d'une appliance VPN peut rester non détectée pendant des semaines ou des mois — le temps moyen de détection d'une intrusion dans les organisations françaises reste supérieur à 100 jours selon les données disponibles des prestataires de réponse à incident.

Ce que ça révèle sur votre architecture de sécurité

La répétition de ces incidents invite à une remise en question fondamentale du modèle de sécurité périmétrique classique, dans lequel l'appliance VPN est le gardien du château. Ce modèle repose sur une hypothèse de confiance implicite : une fois qu'un utilisateur s'est authentifié sur le VPN, il obtient un accès réseau étendu au périmètre interne. Dans de nombreuses organisations, un collaborateur VPN authentifié peut accéder à l'ensemble des segments réseau — serveurs de fichiers, annuaire AD, applications métier, bases de données — sans restriction supplémentaire basée sur son rôle ou le contexte de sa connexion.

La compromission de l'appliance VPN dans ce modèle est catastrophique : l'attaquant contrôle directement le gardien du château et dispose par extension d'un accès direct à l'ensemble du périmètre interne. Le blast radius est maximal. La seule question est combien de temps les défenseurs mettront à détecter l'intrusion — et les statistiques ne sont pas encourageantes.

Ce modèle contraste avec l'approche Zero Trust Network Access (ZTNA), qui part du principe inverse : aucune confiance implicite n'est accordée à aucun flux, même interne. Dans un modèle ZTNA, chaque accès applicatif est contrôlé individuellement, indépendamment de l'appliance d'accès distant. Un utilisateur ne se connecte pas au "réseau interne" mais à des applications spécifiques, avec des contrôles d'accès granulaires incluant l'identité de l'utilisateur, le contexte du poste de travail (patch level, présence d'EDR, certificat machine), et l'heure de la connexion. La compromission d'un composant d'accès distant dans ce modèle ne donne pas accès à l'ensemble du périmètre — seulement aux applications autorisées par la politique, ce qui réduit drastiquement le blast radius d'une compromission.

Les alternatives et mesures de réduction d'exposition disponibles aujourd'hui

La première mesure, la plus basique et la plus fréquemment négligée, est la gestion rigoureuse des patches. Les données disponibles sur chaque incident VPN majeur montrent systématiquement que des milliers d'organisations sont compromises via des CVE pour lesquelles des correctifs étaient disponibles depuis des semaines ou des mois. Mettre en place un processus de patch management accéléré pour les appliances périmètre exposées sur Internet — avec un objectif de 24 à 48 heures pour les CVE critiques exploitées in-the-wild — est la mesure avec le meilleur rapport effort/réduction de risque.

La deuxième mesure est la surveillance continue de l'appliance elle-même. La plupart des organisations qui déploient des agents de surveillance sur leurs serveurs applicatifs n'ont pas d'équivalent sur leurs appliances réseau. Implémenter une collecte centralisée des logs de l'appliance vers un SIEM, surveiller les connexions sortantes depuis l'appliance, et détecter les anomalies d'accès (nouvelles plages IP sources, accès à des segments réseau inhabituels, volume de transfert anormal) permet de réduire significativement le délai de détection post-compromission.

La troisième mesure est l'adoption du modèle ZTNA pour les nouvelles applications et pour la migration progressive des applications existantes. Des solutions ZTNA permettent d'exposer des applications internes sans exposer le réseau interne. L'utilisateur s'authentifie auprès d'un proxy cloud ou d'un composant on-premise, qui vérifie son identité, le contexte de son poste de travail, et lui donne accès uniquement aux ressources autorisées par la politique. L'appliance d'accès n'est plus exposée directement sur Internet avec un accès réseau complet — la surface d'attaque est fondamentalement réduite.

La quatrième mesure est la segmentation réseau post-VPN. Même en maintenant un VPN traditionnel, il est possible de réduire le blast radius en segmentant l'accès des utilisateurs VPN. Plutôt qu'un accès à tout le périmètre interne, les utilisateurs n'accèdent qu'aux VLAN et services dont ils ont réellement besoin dans le cadre de leurs fonctions. Combiné à une authentification forte et à une surveillance des flux, cette segmentation transforme une compromission du VPN en un incident contenu plutôt qu'en une catastrophe généralisée pour le SI.

Ce que vous devez faire si vous avez un VPN en production aujourd'hui

Court terme (cette semaine) : vérifier que votre appliance VPN est à jour sur les derniers patches, consulter le catalogue KEV de la CISA et les avis du CERT-FR pour votre produit spécifique, et activer la journalisation complète sur l'appliance avec centralisation vers un SIEM si ce n'est pas déjà fait. Pour Ivanti Connect Secure, appliquer les patches couvrant CVE-2026-104935, CVE-2026-111357 et CVE-2026-118527 est une priorité absolue en ce début novembre 2026.

Moyen terme (ce trimestre) : conduire un audit de l'architecture de votre accès distant. Identifier quels services et applications sont actuellement accessibles depuis le VPN et si cette exposition est justifiée. Mettre en place une segmentation réseau post-VPN pour les accès les plus sensibles — AD, serveurs de sauvegarde, systèmes industriels. Évaluer une solution ZTNA pour vos applications les plus critiques ou les plus exposées à des utilisateurs externes.

Long terme (cette année) : planifier la migration progressive de votre accès distant vers un modèle ZTNA ou SASE. Cette migration peut être progressive — application par application — sans nécessiter une coupure brutale du VPN existant. Définir une date cible pour la réduction significative de la surface exposée de votre périmètre VPN. Former vos équipes aux concepts Zero Trust et intégrer ces principes dans votre prochain cycle de renouvellement des solutions réseau et sécurité.

Mon avis d'expert

Je vois régulièrement des organisations compromises via leur VPN — et dans 80% des cas, le patch qui aurait évité l'incident était disponible depuis plus d'une semaine. La contrainte opérationnelle "on ne peut pas couper le VPN pendant les heures ouvrées" est compréhensible, mais elle ne justifie pas de laisser une CVE CVSS 9+ non patchée pendant des semaines. La bonne pratique est de maintenir une procédure de patch d'urgence hors heures ouvrées pour les appliances périmètre — avec un déclencheur automatique dès qu'une CVE critique exploitée est publiée pour votre produit. C'est une astreinte de deux heures un soir qui évite potentiellement des mois de gestion d'incident à plusieurs centaines de milliers d'euros. L'autre réalité que je constate : la plupart des organisations qui migrent vers le ZTNA le font après une compromission, pas avant. Ne soyez pas cette organisation.

Conclusion : le problème ne disparaîtra pas avec le prochain patch

Les appliances VPN d'entreprise resteront des cibles prioritaires tant qu'elles seront exposées directement sur Internet avec des accès réseau étendus. Chaque nouveau cycle de vulnérabilités sur ces produits est l'occasion de rappeler que le modèle périmétrique classique atteint ses limites face aux adversaires modernes. La vraie question pour chaque RSSI aujourd'hui n'est pas "est-ce que mon VPN va être vulnérable ?" — il l'est, ou il le sera — mais "est-ce que ma détection et ma réponse sont à la hauteur si mon VPN est compromis demain ?"

La résilience en 2026 ne se construit pas uniquement sur la prévention mais sur la combinaison détection rapide, isolation, et réduction du blast radius. Un modèle ZTNA avec segmentation fine ne rend pas votre infrastructure invulnérable, mais il transforme la compromission d'un composant d'accès en un incident gérable plutôt qu'en une catastrophe existentielle pour votre SI. C'est cette résilience architecturale que nous devons construire, en parallèle des efforts de patch management qui restent une nécessité absolue dans l'immédiat.

Besoin d'un regard expert sur votre sécurité périmétrique ?

Ayi NEDJIMI réalise des audits d'architecture pour évaluer votre exposition périmétrique réelle et vous proposer une feuille de route de réduction des risques adaptée à votre contexte.

Prendre contact