EN
en direct

Cisco corrige un zero-day DoS exploité dans le VPN SSL de ses firewalls ASA et FTD

Le 29 octobre 2026, Cisco a publié des correctifs pour CVE-2026-76418, une faille de déni de service exploitée dans le service VPN SSL de ses firewalls ASA et FTD, déclenchable sans authentification. Pour les équipes réseau, la priorité est de patcher — ou de désactiver l’authentification secondaire sur les groupes de tunnels en attendant.

Une baie sombre d’équipements pare-feu noirs identiques, une seule LED d’alarme ambre allumée sur un appareil au milieu de dizaines d’unités éteintes.

29 octobre 2026. Cisco publie des correctifs pour CVE-2026-76418, une faille de déni de service dans le service VPN SSL de ses firewalls Secure Firewall ASA et Secure Firewall Threat Defense (FTD), déjà exploitée dans la nature. 8,6 — le score CVSS de la faille, qui permet à un attaquant distant non authentifié de faire redémarrer l’équipement. 51 000 — le nombre de boîtiers Cisco ASA exposant leur VPN SSL sur Internet selon Shadowserver. Le point qui compte : c’est la deuxième faille de déni de service exploitable sans authentification dans le VPN SSL de Cisco en trois mois, et celle-ci se déclenche sur un chemin de configuration — l’authentification secondaire des groupes de tunnels — que beaucoup de parcs laissent actif.

Une requête suffit pour éteindre le pare-feu

La vulnérabilité se loge dans le service de VPN SSL d’accès distant des logiciels ASA et FTD. Selon l’avis de Cisco, elle provient d’« erreurs de logique lorsque l’authentification secondaire est configurée sur un groupe de tunnels ». Concrètement, un attaquant peut envoyer une requête forgée au moment de se connecter au VPN SSL d’accès distant et provoquer le rechargement inattendu de l’équipement — un déni de service qui éteint le point d’entrée réseau entier, pas seulement une session.

Deux détails rendent la faille plus dangereuse qu’un simple bug de robustesse. D’abord, l’exploitation ne nécessite aucune authentification : Cisco précise qu’« une connexion VPN réussie n’est pas nécessaire pour atteindre le chemin de traitement affecté ». Ensuite, Cisco PSIRT indique avoir découvert des preuves d’exploitation active en octobre 2026, sans fournir d’indicateurs de compromission ni de détails sur les cibles ou les auteurs. Une faille de déni de service exploitée en aveugle contre des équipements de bordure est une anomalie rare — la plupart des exploitations sauvages visent l’exécution de code, pas le redémarrage d’un pare-feu.

La conséquence opérationnelle est immédiate. Sur un pare-feu qui porte le VPN SSL d’accès distant, un redémarrage forcé coupe l’accès distant de tous les employés, interrompt les sessions établies et, selon la topologie, dégrade la disponibilité de services internes exposés. Une attaque répétée transforme un équipement de bordure en point de défaillance permanent.

La faille vit dans la configuration, pas seulement dans le code

L’aspect le plus trompeur de CVE-2026-76418 est qu’elle ne touche pas tous les déploiements ASA et FTD. Trois conditions doivent être réunies. L’équipement tourne une version vulnérable du logiciel. Le service de connexion VPN SSL d’accès distant est joignable — soit le mot-clé webvpn est présent dans la configuration et le VPN SSL est activé sur au moins une interface. Et l’authentification secondaire est configurée dans la portée du groupe de tunnels.

Cette dernière condition est la clé. Cisco recommande de vérifier, si tunnel-group-list enable est configuré, tous les groupes de tunnels — y compris le groupe par défaut DefaultWEBVPNGroup — pour la présence de secondary-authentication-server-group. L’avis insiste sur un piège précis : si tunnel-group-list enable est absent ou a été retiré via la commande no tunnel-group-list enable, il faut tout de même vérifier le groupe par défaut, car la désactivation de la liste de groupes ne supprime pas l’exposition lorsque ce groupe par défaut utilise l’authentification secondaire.

En clair, un parc peut se croire protégé parce qu’il a désactivé la liste de groupes, alors que le groupe par défaut maintient silencieusement l’authentification secondaire active. La faille récompense les configurations héritées — celles où l’authentification secondaire a été ajoutée il y a des années pour renforcer un accès, et oubliée depuis.

Correctifs et contournement

Les versions corrigées couvrent l’ensemble des branches maintenues. Côté ASA : 9.16.4.104, 9.18.4.96, 9.20.4.50, 9.22.3.200, 9.23.1.48, et 9.24.1.27 ou 9.24.10.1. Côté FTD : 7.0.11, 7.2.13, 7.4.9, 7.6.7, 7.7.14, 10.0.3 et 10.1.1. Les branches 9.16 et antérieures, ainsi que 7.0 et antérieures, sont corrigées uniquement via les versions indiquées — il n’existe pas de correctif pour des versions plus anciennes que ces planchers.

Cisco ne fournit pas de contournement qui élimine la vulnérabilité, mais propose une atténuation temporaire pour les équipes qui ne peuvent pas patcher immédiatement : désactiver l’authentification secondaire sur le groupe par défaut DefaultWEBVPNGroup ou sur toute liste de groupes de tunnels configurée par l’utilisateur. Sur FTD, il faut aussi revoir la politique de VPN d’accès distant déployée et la configuration d’exécution résultante dans FMC ou FDM. C’est une atténuation à considérer comme un palliatif de courte durée : elle réduit la surface d’attaque en supprimant la condition déclenchante, mais elle modifie aussi la posture d’authentification de vos accès distants, ce qui a ses propres implications de sécurité.

Le message de Cisco est sans ambiguïté : « Cisco recommande vivement aux clients de mettre à niveau vers une version corrigée pour remédier à cette vulnérabilité. » Le contournement est une mesure d’urgence, pas une destination.

Un VPN SSL sous pression depuis des mois

Cette faille n’est pas un événement isolé. En août 2026, Cisco avait déjà corrigé CVE-2026-20349, un autre zero-day de déni de service dans les firewalls ASA et FTD avec des sockets d’écoute SSL activés, lui aussi exploité dans la nature. L’année précédente, la campagne ArcaneDoor avait enchaîné les zero-days CVE-2024-20353, CVE-2024-20359, CVE-2025-20362 et CVE-2025-20333 contre des équipements Cisco, poussant la CISA à émettre la directive d’urgence 25-03. Et plus tôt en octobre 2026, Cisco avait alerté sur un zero-day exploité dans son Secure Email Gateway.

La statistique de fond donne la tendance. Depuis novembre 2021, la CISA a signalé 101 failles Cisco comme exploitées dans la nature, dont sept également détournées par des groupes de rançongiciels. Le VPN SSL de Cisco est devenu une surface de déni de service récurrente, et Shadowserver dénombre encore plus de 51 000 boîtiers ASA exposant ce service sur Internet.

Le même jour, Cisco Talos a révélé qu’un acteur APT suivi sous le nom UAT-11473 avait exploité CVE-2026-20127, un contournement d’authentification dans Cisco SD-WAN Catalyst Controller, pour déployer un framework malveillant baptisé KeyDrift (composants PolyFlame et LittleFilch) destiné à intercepter le trafic de contrôle déchiffré et à exfiltrer le matériel de chiffrement du plan de données. L’activité, qui cible les secteurs spatial, de défense et de recherche, partage des infrastructures avec le réseau furtif Silent Train de Volt Typhoon. Les deux annonces, publiées le même jour, dessinent un même constat pour les équipes réseau : les équipements de bordure Cisco sont sous surveillance active, et le déni de service n’est plus une nuisance théorique.

Verdict

Si vous exploitez des firewalls ASA ou FTD exposant le VPN SSL, planifiez la mise à niveau vers une version corrigée dès cette semaine : c’est une faille exploitée dans la nature, déclenchable sans authentification, et le correctif existe pour toutes les branches maintenues. Si vous ne pouvez pas patcher immédiatement, désactivez l’authentification secondaire sur DefaultWEBVPNGroup et sur toute liste de groupes de tunnels — mais vérifiez d’abord l’impact sur votre politique d’accès : ce contournement supprime la condition déclenchante, au prix d’un affaiblissement de l’authentification que vous devrez assumer. Et profitez de l’incident pour recenser votre surface VPN SSL : interrogez vos configurations pour le mot-clé webvpn, supprimez les groupes de tunnels à authentification secondaire devenus inutiles, et restreignez l’accès au portail VPN aux adresses qui en ont réellement besoin. Sur un pare-feu, la meilleure protection contre un déni de service n’est pas seulement le correctif — c’est d’avoir moins de service exposé à éteindre.

Références

Le brief cyber, chaque mardi

Les failles qui comptent, les correctifs à appliquer, en dix minutes de lecture.

Pas de spam. Désinscription en un clic.
à lire ensuite

Sur le même sujet

Cloudflare mesure l’effondrement des attaques DDoS géantes au profit d’essaims de petites attaques

Le 29 octobre 2026, Cloudflare publie son rapport DDoS du troisième trimestre : les attaques de moins de 10 minutes et de moins de 1 Gbit/s bondissent de 208 %, tandis que les attaques supérieures à 1 Tbit/s chutent de 69 %. Pour l’exploitant, la défense change de nature : il ne s’agit plus de survivre à une attaque massive, mais d’absorber des milliers de rafales courtes et bon marché, automatiquement.

Une panne de fournisseur de transit dégrade Cloudflare pendant près de trois heures en Amérique du Nord

Le 23 octobre 2026, de 15 h 47 à 18 h 43 UTC, une panne chez un fournisseur de connectivité a saturé les liens entre les centres de données Cloudflare d’Ashburn et d’Atlanta, dégradant des services sans lien direct avec ce fournisseur. Pour qui dépend d’un CDN ou d’un cloud, la leçon est nette : la redondance se vérifie, elle ne se suppose pas.

← Retour au fil

Tapez au moins deux caractères.

↑ ↓ naviguer ↵ ouvrir esc fermer