Cisco ASA et FTD : une requête VPN peut redémarrer le pare-feu

Avis Cisco du 28 octobre 2026. Cisco PSIRT confirme l’exploitation de CVE-2026-76418, une faille du service SSL VPN de Secure Firewall ASA et FTD. Lorsqu’une authentification secondaire est configurée sur un groupe de tunnels, une requête spécialement construite par un acteur non authentifié peut provoquer le redémarrage inattendu de l’équipement. L’impact publié est un déni de service, pas une RCE ni un contournement de connexion.

Pourquoi une demande de connexion peut atteindre le pare-feu avant l’identité

Une passerelle VPN doit recevoir et analyser les premiers messages d’un client avant de savoir s’il est autorisé. Ces messages peuvent préciser un groupe, un flux d’authentification et divers paramètres. Lorsque le groupe utilise une deuxième étape d’authentification, le code doit gérer des états supplémentaires : première identité absente, en attente, validée ou refusée, puis deuxième facteur attendu ou non. Cisco attribue le défaut à des erreurs de logique dans ce contexte. L’avis ne publie ni le champ exact ni la fonction qui redémarre l’appareil ; un schéma de machine à états explique le risque, mais ne doit pas être présenté comme le code réel de l’exploit.

L’absence de privilège dans le vecteur CVSS est cohérente avec cette position du bug : le trafic malveillant arrive avant l’authentification réussie. La précondition de configuration, elle, est essentielle. Un ASA ou FTD sans groupe de tunnels configuré pour l’authentification secondaire ne correspond pas au périmètre décrit par Cisco, même s’il porte la même famille de produits. Il faut vérifier les deux dimensions : version et configuration.

Le risque opérationnel

Un redémarrage de pare-feu peut couper des sessions VPN existantes, retarder les reconnexions et interrompre les chemins que l’équipement protège. Si l’attaquant peut répéter la requête, les interruptions peuvent se prolonger ; le bulletin ne quantifie toutefois ni la durée du redémarrage ni la fréquence de succès d’une campagne. Des configurations redondantes peuvent limiter l’effet visible, mais il faut tester leur bascule réelle. Décrire cette faille comme « seulement un crash » sous-estime la position de l’appliance dans l’accès distant.

Un audit autorisé s’appuierait sur un laboratoire avec versions corrigée et vulnérable, groupes avec et sans authentification secondaire, et surveillance des états du service VPN. Le test utile serait de confirmer que la demande déclenche le défaut seulement dans la configuration affectée et que la version corrigée rejette la même entrée sans redémarrer. Cisco indique que la découverte a eu lieu pendant la résolution d’un dossier de support TAC, et non dans un PoC public détaillé ; l’avis ne permet pas de publier une charge utile exacte vérifiée.

Corriger et rechercher

Cisco ne donne aucun contournement dans l’avis et demande la mise à jour vers une version fixe applicable au train ASA ou FTD exploité. L’équipe d’exploitation doit relever les versions, la présence d’authentification secondaire, les redémarrages inattendus et les requêtes SSL VPN précédentes. Une hausse de redémarrages après des tentatives de connexion est un signal d’enquête, pas une attribution automatique à cette CVE.

La leçon est que la disponibilité d’un équipement de sécurité dépend aussi de ses chemins préauthentification et de ses combinaisons de configuration. Le test du flux nominal, avec deux facteurs réussis, ne couvre pas les états malformés que peut envoyer un client hostile.

Source principale : Cisco Security Advisory cisco-sa-asaftd-tunnel-dos-s6mgkb75.