Zero-day Ivanti Connect Secure : la leçon pour WireGuard

Brève du 18 octobre 2026. Article d'origine : Cybernews, 16 octobre 2026 (en anglais).

Des attaquants ont enchaîné trois vulnérabilités zero-day dans Ivanti Connect Secure (ICS), le boîtier VPN SSL que beaucoup d'entreprises placent devant leur réseau, pour obtenir l'exécution de code en root sans authentification, sur des appareils pourtant à jour. Cybernews rapporte le 16 octobre que la CISA demande de patcher immédiatement, et que l'une des trois failles n'a toujours pas de correctif.

Ce qui s'est passé

• À partir du 3 octobre 2026, un acteur jusque-là inconnu, suivi sous le nom UTA0576, a exploité la chaîne en conditions réelles, selon Volexity, qui l'a découverte sur un boîtier en 22.8R2.4, la dernière version à ce moment-là.
• La chaîne combine un contournement d'authentification, une exécution de code à distance et une élévation de privilèges. Les deux premiers sont suivis sous CVE-2026-104935.
• 13 octobre : Ivanti prévient ses clients et la CISA ajoute CVE-2026-104935 à son catalogue KEV, avec une échéance de correction au 16 octobre pour les agences fédérales américaines.
• Ivanti affirme avoir trouvé une partie du bug lors de ses propres tests et l'avoir corrigée dans la version de juillet 25.1.3.0, mais le correctif était encore en cours de portage vers les autres versions maintenues quand l'exploitation a commencé.
• Volexity a vu l'attaquant viser les identifiants Active Directory, les mots de passe LAPS et les clés de récupération BitLocker. Aucun web shell laissé sur place : l'acteur réexploitait l'appareil pour chaque commande et modifiait les journaux.

Si vous utilisez Ivanti Connect Secure

1. Appliquez la mise à jour d'Ivanti maintenant. Versions citées comme affectées : 25.1.1.1 et antérieures, 25.1.2.2 et antérieures, 22.8R2.4 et antérieures.
2. Ne vous fiez pas au seul Integrity Checker Tool. Volexity explique que l'exploit modifie le code en mémoire uniquement, donc le contrôle du disque reste vert. La CISA demande une analyse forensique réseau et mémoire.
3. Cherchez dans vos journaux les requêtes vers /dana-na/auth/url_default/welcome.cgi qui portent un en-tête X-DSCGI-PATH. C'est le ressort du contournement : l'URL est une page de connexion publique, l'en-tête désigne un script qui ne devrait jamais être joignable sans session. Yordan Ganchev, de watchTowr, s'attend auprès de Cybernews à un passage « incroyablement rapide » vers l'exploitation de masse.
4. Considérez comme exposés les identifiants passés par le boîtier si vous trouvez une trace : comptes AD, LAPS, clés BitLocker. Changez-les.

Pourquoi les boîtiers VPN SSL reviennent sans cesse sur cette liste

Ganchev rappelle que ce n'est pas une première : Ivanti Connect Secure et son prédécesseur Pulse Connect Secure comptaient déjà 14 autres entrées au catalogue de la CISA. Le point commun est structurel. Un boîtier VPN SSL fait tourner un serveur web qui répond à n'importe qui sur Internet avant toute connexion : page de login, scripts CGI, analyse d'en-têtes, logique de session. Chacune de ces lignes de code est accessible à un attaquant sans compte. Le contournement de CVE-2026-104935 en est un cas d'école : une partie du code faisait confiance à l'URL, une autre à un en-tête.

Ce qu'un port WireGuard fait autrement

Un serveur WireGuard n'a pas de page de connexion. Son port UDP ne réagit qu'à une initiation de handshake calculée avec la clé publique du serveur. Tout le reste, scanner, paquet malformé ou requête HTTP, est jeté sans réponse. Un scanner voit un port qui ne répond jamais, comme un port filtré par un pare-feu, et c'est pour cela que vérifier que votre port WireGuard est joignable se fait avec un vrai handshake client plutôt qu'avec un scanner de ports. La surface accessible sans clé est un message cryptographique de taille fixe, pas une application web.

C'est une vraie différence, mais pas de la magie. Soyons honnêtes sur ce qui reste à votre charge :

• L'hôte doit toujours être patché. Un serveur WireGuard sur un VPS n'est pas plus sûr que son SSH, son noyau et tout ce que vous exposez d'autre. Gardez le reste de la machine fermé.
• Les clés sont l'identité. Une clé privée volée permet d'usurper un pair. L'affaire de la clé WireGuard exposée sur MikroTik montre que le risque se déplace là où les clés sont stockées.
• Pas d'utilisateurs, pas de MFA, pas de SSO. WireGuard seul connaît des clés publiques, pas des personnes. Pour une équipe qui a besoin d'accès par utilisateur et d'authentification unique, un plan de contrôle comme Headscale ou NetBird ajoute cette couche au-dessus de WireGuard.
• Ce n'est pas un remplacement clé en main d'un déploiement de 500 postes avec contrôle de conformité. Pour une petite équipe, un homelab ou quelques admins qui doivent entrer dans un réseau, c'est souvent suffisant.

Une alternative petite et lisible

Si vous êtes une petite équipe et que vous hésitez à garder un boîtier VPN exposé sur le web, la voie auto-hébergée tient en un VPS avec une IPv4 publique, un port UDP et une configuration que vous pouvez relire en entier. Notre générateur de configuration WireGuard, gratuit, écrit dans votre navigateur des fichiers serveur et client qui correspondent, et le guide pas à pas Contabo + WireGuard couvre la partie serveur.

Sources

• Cybernews, Stefanie Schappert, Ivanti's three-headed zero-day exploited in the wild: CISA says patch now, but one flaw has no fix, 16 octobre 2026.
• Volexity, A Series of Unauthenticated Events: Chained Exploitation of Ivanti Connect Secure Zero-Days, 13 octobre 2026.
• CISA, catalogue Known Exploited Vulnerabilities, entrée CVE-2026-104935 ajoutée le 13 octobre 2026.