DoS SSL VPN Cisco ASA et FTD exploité dans la nature (CVE-2026-76418)

En bref

• CVE-2026-76418 est une faille de déni de service dans le service SSL VPN d’accès distant de Cisco Secure Firewall ASA et FTD Software. Un attaquant distant non authentifié envoie une requête spécialement conçue pendant la connexion au VPN SSL et l’équipement redémarre de façon inattendue. Cisco la note High, CVSS v3.1 8,6 avec le vecteur CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:N/I:N/A:H.
• La fiche CVE nomme 209 versions ASA et FTD affectées ; le tableau ci-dessous les répartit par ligne. Un équipement n’est exposé que si trois conditions sont réunies : il exécute une version vulnérable, le service de connexion SSL VPN d’accès distant est accessible et l’authentification secondaire est configurée sur un tunnel group. Une connexion VPN réussie n’est pas nécessaire pour atteindre le chemin de traitement affecté.
• Cisco indique que son Product Security Incident Response Team a eu connaissance d’une exploitation active de cette vulnérabilité en octobre 2026, sans donner de dates, d’acteurs ni d’ampleur. La faille ne figure pas dans le catalogue CISA KEV au 29 octobre 2026.
• Mettez immédiatement à jour vers la première version corrigée de votre ligne. Le tableau ci-dessous couvre les quinze lignes affectées : le bulletin donne une version corrigée pour treize d’entre elles, et la note après le tableau traite d’ASA 9.19 et de FTD 7.3. Si vous ne pouvez pas mettre à jour aujourd’hui, l’atténuation de Cisco, ses deux cas et leurs contreparties figurent dans « Comment corriger le problème ? ».

Suis-je concerné ?

Votre équipement n’est exposé que si toutes ces conditions sont réunies :

• Il exécute une version vulnérable de Cisco Secure Firewall ASA Software ou Cisco Secure FTD Software. Cisco a confirmé que Cloud-delivered Firewall (CDFW), Cloud-delivered Firewall Management Center (cdFMC), Secure Access (CSA) et Secure FMC Software ne sont pas affectés.
• Le service de connexion SSL VPN d’accès distant est accessible : la configuration en cours contient le mot-clé webvpn avec le SSL VPN activé sur au moins une interface. Sur FTD, les fonctions de VPN d’accès distant sont activées depuis Devices > VPN > Remote Access dans Secure FMC ou depuis Remote Access VPN dans Secure FDM.
• L’authentification secondaire est configurée dans le périmètre d’un tunnel group. Si tunnel-group-list enable est configuré, vérifiez tous les tunnel groups, y compris le tunnel group par défaut DefaultWEBVPNGroup, pour secondary-authentication-server-group. Si la liste des groupes est absente ou a été retirée avec no tunnel-group-list enable, vérifiez quand même DefaultWEBVPNGroup : désactiver la liste des groupes ne supprime pas l’exposition lorsque le groupe par défaut utilise l’authentification secondaire.

Deux lignes manquent au tableau des versions corrigées du bulletin alors que la fiche CVE cite des builds affectés : ASA 9.19.1 à 9.19.1.42 et FTD 7.3.0 à 7.3.1.2. Les responsables de ces lignes devraient utiliser le Cisco Software Checker lié dans le bulletin, qui renvoie la première version corrigée pour un numéro de version précis. La fiche CVE nomme 142 versions ASA affectées et 67 versions FTD affectées, et chacune nécessite le correctif.

Dans quatre lignes, la fiche cite aussi des builds numérotés au-delà de la première version corrigée du bulletin : 9.18.4.135, 9.20.4.235, 9.23.1.195 et 9.24.1.155. Aucune des deux sources ne les explique : pour un tel build, vérifiez le numéro de version exact dans le Software Checker plutôt que de le comparer au tableau.

Vérifiez le logiciel en cours et les deux conditions de configuration sur chaque équipement :

show version                          # running software release and uptime
show run webvpn                       # webvpn enable <interface> lines: is the SSL VPN service on?
show run tunnel-group | include tunnel-group|secondary-authentication-server-group   # each tunnel group, followed by its secondary authentication line if any
show run tunnel-group DefaultWEBVPNGroup | include secondary-authentication-server-group   # the default group, even without a group list

Les trois dernières commandes sont adaptées des mots-clés de configuration cités par le bulletin de Cisco (webvpn enable, tunnel-group-list enable, secondary-authentication-server-group). Une ligne secondary-authentication-server-group qui nomme un groupe de serveurs, et non none, signifie que l’authentification secondaire est active pour ce tunnel group.

Sur FTD, les tunnel groups se trouvent dans la stratégie VPN d’accès distant que Secure FMC ou Secure FDM déploie sur l’équipement. Vérifiez-y cette stratégie déployée et la configuration en cours qui en résulte. Pour trouver la version corrigée de votre build exact, passez-le dans le Software Checker lié plus haut.

Comment corriger le problème ?

Passez à la première version corrigée de votre branche dans le tableau ci-dessus, en suivant les guides de mise à niveau ASA ou FTD de Cisco. Sur les équipements FTD, la mise à niveau passe par Cisco Secure FMC ou Secure FDM, et non à la main sur l’équipement. Cisco considère toute atténuation comme temporaire jusqu’à la mise à niveau.

Le bulletin de Cisco indique qu’il n’existe aucune solution de contournement. Il donne une atténuation, qui supprime la condition de configuration dont l’attaque a besoin :

• Cas 1 : si DefaultWEBVPNGroup n’utilise pas l’authentification secondaire, désactivez la liste des tunnel groups. En mode de configuration webvpn, entrez no tunnel-group-list enable. Les utilisateurs ne peuvent alors plus choisir un profil de connexion dans une liste sur la page de connexion et doivent connaître le nom du profil à utiliser.
• Cas 2 : si DefaultWEBVPNGroup utilise l’authentification secondaire, retirez-la avec la commande no secondary-authentication-server-group. Cela réduit le niveau de sécurité du VPN d’accès distant, car les connexions perdent leur deuxième étape d’authentification.

Les deux cas énoncent clairement leur coût : l’atténuation échange une fonctionnalité de connexion ou un deuxième facteur d’authentification contre la suppression du chemin de traitement vulnérable. Cisco a déployé l’atténuation dans un environnement de test et demande à chaque client de l’évaluer dans le sien. Aucun cas ne modifie le logiciel : la mise à niveau reste le correctif.

Quelle est la cause racine ?

Le service SSL VPN d’accès distant traite mal une requête qui arrive pendant que l’authentification secondaire est configurée sur un tunnel group, et cette mauvaise gestion est une valeur de retour non vérifiée qui se termine par un déréférencement de pointeur NULL.

Cisco attribue CWE-690, Unchecked Return Value to NULL Pointer Dereference, à cette faille. La chaîne causale du bulletin a trois maillons : la vulnérabilité est due à des « erreurs de logique lorsque l’authentification secondaire est configurée sur un tunnel group » ; l’attaquant l’exploite « en envoyant une requête spécialement conçue lors de la connexion au VPN SSL d’accès distant » ; et une exploitation réussie « pourrait permettre à l’attaquant de provoquer le redémarrage de l’équipement ».

Trois détails du bulletin délimitent précisément l’exposition. D’abord, la requête fait partie de la connexion, pas de l’authentification : « une connexion VPN réussie n’est pas nécessaire pour atteindre le chemin de traitement affecté ». Ensuite, le déclencheur dépend de la configuration : sans authentification secondaire sur un tunnel group, la requête conçue n’atteint jamais la logique défaillante. Enfin, la faille a été trouvée par Eric Fernald lors de la résolution d’un dossier d’assistance du Cisco Technical Assistance Center, ce qui laisse penser que le plantage a d’abord été observé chez un client plutôt qu’en recherche.

Cisco ne publie pas le code source d’ASA ni de FTD Software, donc l’appel défaillant exact n’est pas public. Ce qui est public, c’est le périmètre du bug : il est atteignable avant la connexion, il nécessite la configuration d’authentification secondaire et son seul impact documenté est un redémarrage de l’équipement.

Comment la faille est-elle exploitée ?

Aucune preuve de concept n’est publique, donc les étapes ci-dessous suivent la description de l’attaque donnée par le bulletin.

1. L’attaquant se connecte au point de terminaison SSL VPN d’accès distant de l’équipement, la page de connexion qu’un utilisateur distant atteint avant l’acceptation de quelque identifiant que ce soit.
2. Pendant la connexion, l’attaquant envoie une requête spécialement conçue au lieu d’une tentative de connexion ordinaire. La requête atteint le chemin de code qui applique l’authentification secondaire d’un tunnel group.
3. Ce chemin de code traite la requête conçue avec une erreur de logique : une valeur de retour non vérifiée se termine par un déréférencement de pointeur NULL dans le service VPN.
4. Le déréférencement fait planter le processus et l’équipement redémarre. Chaque session VPN sur l’équipement s’interrompt avec lui et la coupure dure pendant tout le redémarrage.
5. Rien n’authentifie l’attaquant à aucune étape, et le bulletin ne cite rien qui empêche de renvoyer la même requête conçue dès que l’équipement est de retour, ce qui pourrait transformer un redémarrage en interruption durable.

Quel est le déroulement de l’attaque ?

La chaîne est courte : une requête conçue non authentifiée atteint le chemin d’authentification secondaire, une valeur non vérifiée devient un déréférencement NULL et tout l’équipement redémarre.

Que peut faire un attaquant ?

L’attaquant peut faire planter un pare-feu ou un équipement VPN exposé à distance, sans identifiants, et le bulletin n’indique aucune limite à la répétition de l’attaque. Le vecteur CVSS évalue l’impact sur la disponibilité uniquement : confidentialité None, intégrité None, disponibilité High. La portée est Changed ; Cisco n’explique pas ce choix, qui est cohérent avec une faille située dans le service VPN qui fait tomber tout l’équipement.

Les conditions dont l’attaque a besoin sont précises et elles réduisent le périmètre des personnes exposées :

• Un accès réseau au service de connexion SSL VPN d’accès distant. L’attaquant n’a besoin ni d’un compte VPN, ni d’identifiants valides, ni d’une connexion réussie.
• L’authentification secondaire configurée dans le périmètre d’un tunnel group, sur un groupe défini par l’utilisateur ou sur DefaultWEBVPNGroup. Un équipement sans authentification secondaire nulle part n’est pas exposé, quelle que soit sa version.
• Une version vulnérable. La liste des versions affectées de la fiche CVE commence à ASA 9.16.1 et FTD 7.0.0, et le tableau des versions corrigées du bulletin couvre aussi ASA 9.16 et antérieur et FTD 7.0 et antérieur.

Pourquoi le correctif fonctionne-t-il ?

Les versions corrigées de chaque ligne arrivent dans le même bulletin et corrigent les erreurs de logique du chemin d’authentification secondaire. Cisco valide lui-même les informations de versions affectées et corrigées et ne publie aucun diff de correctif, donc l’exhaustivité du correctif repose sur la déclaration de l’éditeur selon laquelle les premières versions corrigées listées sont les premières qui le contiennent.

L’atténuation agit plutôt sur la configuration. Le cas 2 retire l’authentification secondaire, troisième condition d’exposition, donc la requête conçue n’a plus de logique défaillante à atteindre. Le cas 1, proposé uniquement lorsque DefaultWEBVPNGroup n’a pas d’authentification secondaire, désactive plutôt la liste des tunnel groups. Cisco indique que l’atténuation a fait ses preuves dans un environnement de test et la considère toujours comme temporaire, et elle cesse de fonctionner dès que la configuration est rétablie.

Comment vérifier si j’ai été compromis ?

Cisco indique que la faille est exploitée mais n’a publié ni indicateurs, ni détails d’attaque, ni dates, ni ampleur, donc il n’existe aucun IOC éditeur à chercher. Ce qu’un administrateur peut vérifier, c’est le plantage lui-même, car un déréférencement de pointeur NULL laisse un redémarrage derrière lui :

show version          # uptime since the last reload
show crashinfo        # the crash dump from the last software fault, when one was written

Un équipement qui a redémarré de lui-même, ou un dump de plantage pointant dans le code du service VPN d’accès distant, sur un équipement qui remplit les trois conditions d’exposition, doit être traité comme une tentative d’exploitation possible. Capturez le crashinfo, notez les adresses sources dans les journaux VPN autour du redémarrage et signalez le cas au PSIRT de Cisco, qui indique être au courant d’une exploitation active. Une tentative qui n’a pas fait planter l’équipement ne laisse ni redémarrage ni dump de plantage : un uptime sans interruption ne prouve donc pas que l’équipement n’a jamais été visé.

Chronologie

• Octobre 2026 : le PSIRT de Cisco prend connaissance d’une exploitation active de cette vulnérabilité. Cisco n’a pas publié de date plus précise que le mois.
• 2026-10-28 : Cisco publie le bulletin cisco-sa-asaftd-tunnel-dos-s6mgkb75 avec les premières versions corrigées de treize lignes logicielles et la note CVSS v3.1 8,6. Le même jour, la fiche CVE-2026-76418 est publiée avec CWE-690.
• 2026-10-29 : The Hacker News couvre le bulletin et la déclaration d’exploitation active.

FAQ

Mon équipement est-il exposé si je n’ai jamais configuré d’authentification secondaire ?

Non. L’exposition exige les trois conditions : une version vulnérable, un service de connexion SSL VPN d’accès distant accessible et une authentification secondaire configurée dans le périmètre d’un tunnel group. Sans la dernière condition, la requête conçue n’atteint jamais la logique défaillante, et le cas 2 de l’atténuation de Cisco consiste précisément à la retirer.

L’attaquant a-t-il besoin d’identifiants VPN valides ?

Non. Le bulletin indique qu’« une connexion VPN réussie n’est pas nécessaire pour atteindre le chemin de traitement affecté », et le vecteur CVSS porte Privileges Required : None. L’attaque se produit pendant la connexion, avant qu’un identifiant puisse être vérifié.

Désactiver la liste des tunnel groups supprime-t-il l’exposition ?

Pas en soi. Cisco avertit que si tunnel-group-list enable est absent ou a été retiré avec no tunnel-group-list enable, le tunnel group par défaut DefaultWEBVPNGroup expose quand même l’équipement lorsqu’il utilise l’authentification secondaire. Vérifiez la présence de secondary-authentication-server-group sur le groupe par défaut, quel que soit le réglage de la liste des groupes.

Cette vulnérabilité figure-t-elle dans le catalogue CISA KEV ?

Non. Le catalogue Known Exploited Vulnerabilities de CISA ne liste pas CVE-2026-76418 au 29 octobre 2026, vérifié sur le flux JSON du catalogue à cette date. La déclaration d’exploitation active vient du bulletin de Cisco du 28 octobre 2026.

Vers quelle version corrigée mettre à jour ?

Le bulletin liste une première version corrigée par branche, sauf pour 9.24, qui en a deux : 9.24.1.27 et 9.24.10.1. Le Cisco Software Checker prend un numéro de version précis et renvoie la première version corrigée pour tous les bulletins qui l’affectent, ce qui est le moyen le plus sûr de choisir une cible pour un équipement qui exécute un build inhabituel.

Repérez les points d’accès VPN ASA et FTD exposés avec Ostorlab

Utilisez Ostorlab Attack Surface Discovery pour inventorier les hôtes exposés à internet qui vous appartiennent et repérer les équipements ASA et FTD qui exposent le service de connexion SSL VPN d’accès distant, afin de savoir lesquels vérifier pour l’authentification secondaire et mettre à jour en premier.

Références

• Bulletin de sécurité Cisco cisco-sa-asaftd-tunnel-dos-s6mgkb75, « Cisco Secure Firewall Adaptive Security Appliance and Secure Firewall Threat Defense Software Remote Access SSL VPN Tunnel Denial of Service Vulnerability », publié le 28 octobre 2026 à 19 h 15 GMT : le résumé, les trois conditions d’exposition, les conseils de configuration des tunnel groups, les deux cas d’atténuation, les tableaux de versions corrigées, la déclaration d’exploitation active et l’attribution à Eric Fernald via un dossier TAC : https://sec.cloudapps.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-asaftd-tunnel-dos-s6mgkb75 (consulté le 29 octobre 2026)
• Fiche CVE-2026-76418, publiée le 28 octobre 2026 par le CNA Cisco, avec le vecteur de base CVSS v3.1 8,6, CWE-690 et la liste des versions affectées : https://www.cve.org/CVERecord?id=CVE-2026-76418 (consultée le 29 octobre 2026)
• The Hacker News, « Cisco Patches Actively Exploited ASA and FTD VPN Flaw That Can Crash Firewalls », 29 octobre 2026 : https://thehackernews.com/2026/10/cisco-patches-actively-exploited-asa.html (consulté le 29 octobre 2026)
• Flux JSON du catalogue CISA Known Exploited Vulnerabilities, vérifié pour CVE-2026-76418 le 29 octobre 2026 (absent) : https://www.cisa.gov/sites/default/files/feeds/known_exploited_vulnerabilities.json