Responsable réponse à incident
Le pare-feu qui redémarre tout seul : 12 versions Cisco concernées, et les 5 vérifications que j’ai lancées le soir même
TL;DR
- CVE-2026-20349 touche le service Remote Access SSL VPN de Cisco Secure Firewall ASA et FTD. Une requête HTTP spécialement forgée fait redémarrer l’équipement — déni de service, sans authentification et sans interaction utilisateur.
- Exploitée dans la nature : la faille figure au catalogue KEV de la CISA, avec une échéance de remédiation fixée au 14 août 2026 pour les agences fédérales civiles américaines.
- Périmètre : ASA 9.16, 9.18, 9.20, 9.22, 9.23 et 9.24 ; FTD 7.0, 7.2, 7.4, 7.6, 7.7 et 10.0. Fonctionnalités concernées : IKEv2 Remote Access VPN, SSL VPN et Zero Trust Network Access.
- Aucun contournement disponible, et aucun indicateur de compromission spécifique : vous ne saurez pas si vous avez été visé. Cisco a publié des correctifs.
- Ce qu’il faut retenir : une échéance fédérale américaine n’a aucune valeur juridique en France, mais elle constitue le meilleur signal public de gravité dont vous disposiez.
Il y a une catégorie de vulnérabilités qui me fait lever les yeux au ciel, et une autre qui me fait ouvrir un canal d’astreinte. CVE-2026-20349 appartient à la seconde, pour une raison précise : elle vise le service qui, dans la plupart des PME que nous accompagnons, constitue à la fois la porte d’entrée des télétravailleurs et le premier rempart du réseau.
La faille réside dans le service Remote Access SSL VPN de Cisco Secure Firewall ASA et FTD. Une requête HTTP spécialement forgée envoyée à ce service provoque un redémarrage inattendu de l’équipement, c’est-à-dire un déni de service. Aucune authentification n’est requise. Aucune action d’un utilisateur légitime n’est nécessaire. Il suffit que le service soit exposé, ce qui est précisément sa raison d’être.
Ce que dit exactement l’avis
Les versions concernées couvrent une large partie du parc installé. Côté ASA Software : 9.16, 9.18, 9.20, 9.22, 9.23 et 9.24. Côté FTD Software : 7.0, 7.2, 7.4, 7.6, 7.7 et 10.0. Les fonctionnalités touchées sont l’IKEv2 Remote Access VPN, le SSL VPN et le Zero Trust Network Access — autrement dit, l’essentiel de ce pour quoi ces boîtiers sont déployés en périphérie.
Deux précisions de l’avis méritent d’être lues attentivement, parce qu’elles ferment des portes que l’on aimerait garder ouvertes. La première : il n’existe pas de contournement. On ne peut pas désactiver un sous-composant ni ajouter une règle de filtrage qui neutraliserait proprement le problème sans casser le service. La seconde : il n’existe pas d’indicateur de compromission spécifique. Vous ne pourrez pas déterminer rétrospectivement si votre équipement a été visé.
Cisco a publié des correctifs pour les versions concernées. La faille figure par ailleurs au catalogue des vulnérabilités activement exploitées de la CISA, avec une date limite de remédiation fixée au 14 août 2026 pour les agences fédérales civiles américaines.
Notre avis d’expert #1 — Le déni de service est sous-estimé parce qu’il ne vole rien
Quand une vulnérabilité n’entraîne « qu’un » déni de service, la réaction habituelle en comité est de la classer en dessous d’une exécution de code. C’est une erreur de raisonnement quand la cible est le concentrateur VPN. Pour une PME dont une partie des équipes travaille à distance, faire tomber le VPN ne dégrade pas le service : il arrête l’entreprise. Personne n’accède aux applications internes, le support ne peut plus intervenir, et l’équipe qui doit corriger le problème est elle-même coupée de l’infrastructure.
Ajoutez que le redémarrage peut être déclenché en boucle, et vous obtenez une indisponibilité entretenue plutôt qu’un incident ponctuel. Le bon critère de priorisation n’est pas la nature technique de l’impact, c’est la place de l’équipement dans votre chaîne de dépendances.
Les 5 vérifications que nous avons lancées
1. Établir la liste réelle des équipements exposés. Pas la liste théorique de l’inventaire, celle du terrain. Nous demandons systématiquement une vue depuis l’extérieur, parce que l’écart entre les deux est constant : un boîtier de secours laissé branché après une migration, un site distant racheté dont le pare-feu n’a jamais rejoint le référentiel, un environnement de test devenu permanent.
2. Relever la version exacte de chaque équipement. Les branches de version sont proches et la lecture est piégeuse : 9.20 et 9.22 se ressemblent dans un tableau. Nous exigeons un relevé sorti de l’équipement, pas recopié d’une fiche.
3. Vérifier si les fonctionnalités concernées sont réellement actives. Un ASA déployé uniquement en filtrage, sans service d’accès distant activé, n’est pas dans la même situation qu’un concentrateur VPN en frontal. Cette vérification ne change pas la nécessité du correctif, mais elle change l’ordre dans lequel vous traitez un parc de trente boîtiers en une nuit.
4. Confirmer la fenêtre de redémarrage. Appliquer un correctif sur un équipement de périphérie implique une coupure. La question à poser au métier n’est pas « peut-on couper ? » mais « préférez-vous une coupure de vingt minutes que vous choisissez, ou une coupure que quelqu’un d’autre choisira ? ». Posée ainsi, la réponse arrive vite.
5. Préparer le retour arrière avant d’appliquer. Sauvegarde de configuration exportée hors de l’équipement, accès console physique ou hors bande vérifié, et une personne joignable sur site. Un correctif de pare-feu qui se passe mal vous prive du canal par lequel vous auriez réparé.
Vous ne savez pas combien d’équipements exposés vous avez réellement ?
C’est le cas de la majorité des PME que nous auditons, et c’est ce qui transforme un correctif de routine en semaine difficile. Nous cartographions votre surface exposée et vous rendons la liste, version par version.
Discutons-enNotre avis d’expert #2 — L’échéance de la CISA n’est pas votre obligation, mais c’est votre meilleur signal
Une remarque revient à chaque fois qu’une date KEV apparaît dans un rapport : « nous ne sommes pas une agence fédérale américaine ». C’est exact, et cette échéance n’a aucune portée juridique en France. Mais elle reste l’information la plus utile de tout l’avis, parce qu’elle vous dit quelque chose que le score de sévérité ne dit pas : qu’une autorité a jugé l’exploitation suffisamment réelle et suffisamment répandue pour imposer une action contrainte.
Nous l’utilisons donc comme critère de tri opérationnel plutôt que comme obligation. Une vulnérabilité inscrite au KEV passe devant une vulnérabilité au score plus élevé mais sans exploitation constatée. C’est un renversement de priorité que beaucoup d’organisations n’ont pas encore intégré, et c’est probablement le changement de méthode le plus rentable de ces dernières années.
Le problème de fond : le pare-feu est un actif, pas un meuble
Ce qui rend ce type d’épisode pénible n’est presque jamais la vulnérabilité elle-même. C’est le temps passé à répondre à des questions qui auraient dû avoir une réponse écrite : combien d’équipements, quelles versions, qui a le droit de redémarrer, où est la sauvegarde de configuration, qui prévient les utilisateurs.
Les équipements de périphérie souffrent d’un biais particulier : ils fonctionnent pendant des années sans demander d’attention, et finissent par être traités comme du mobilier. Ils sont pourtant, avec les serveurs d’authentification, les actifs dont la compromission a la portée la plus large. Le seul remède est ennuyeux : un inventaire à jour, une politique de mise à jour écrite, et une fenêtre de maintenance déjà négociée avec le métier avant qu’on en ait besoin.
Notre avis d’expert #3 — Ce que change l’absence d’indicateurs de compromission
C’est la ligne de l’avis que je trouve la plus instructive, et celle que les synthèses omettent. Sans indicateur de compromission spécifique, vous ne pouvez pas répondre à la question que votre direction posera immanquablement : « est-ce qu’on nous a attaqués ? ». La réponse honnête est « nous ne pouvons pas le savoir », et il vaut mieux l’avoir préparée que l’improviser.
Cela a une conséquence pratique. En l’absence de traces côté équipement, vos seules sources sont vos propres journaux : redémarrages inexpliqués, coupures VPN brèves attribuées à un incident réseau, tickets utilisateurs classés sans suite. Si vous ne conservez pas ces éléments de façon centralisée, l’analyse rétrospective est simplement impossible. C’est un argument concret en faveur de la journalisation externalisée, bien plus convaincant qu’un chapitre de norme.
Et si vous ne pouvez pas corriger tout de suite
La situation est fréquente : contrat de maintenance expiré, version trop ancienne pour recevoir le correctif, ou dépendance applicative qui interdit la mise à jour cette semaine. Dans ce cas, l’honnêteté consiste à traiter la période comme un risque accepté et documenté, pas comme un sujet en attente.
Concrètement : restreindre autant que possible les adresses sources autorisées à joindre le service d’accès distant, surveiller activement les redémarrages de l’équipement, préparer un mode dégradé permettant au métier de fonctionner sans VPN pendant quelques heures, et fixer une date d’application ferme avec un responsable nommé. Aucune de ces mesures ne corrige la vulnérabilité — mais elles évitent que « on ne peut pas patcher maintenant » devienne « on n’a jamais patché ».
Sur le volet inventaire et périmètre, notre page audit de périmètre NIS2 détaille la méthode que nous appliquons pour reconstruire une vue exacte de la surface exposée. Et pour les équipes qui gèrent aussi la chaîne logicielle interne, les confrères de D-Open ont documenté cette semaine un cas voisin de gestion de clés de signature, tandis que Plug-Tech traite la question des agents automatisés disposant d’accès privilégiés à l’infrastructure.
Questions fréquentes
Sommes-nous concernés si nous n’utilisons pas le VPN SSL ?
Les fonctionnalités visées sont l’IKEv2 Remote Access VPN, le SSL VPN et le Zero Trust Network Access. Si aucune n’est activée sur un équipement, son exposition à cette faille précise est très différente. Cela ne dispense pas d’appliquer le correctif : cela vous permet seulement de traiter d’abord les équipements réellement en frontal. Vérifiez la configuration effective plutôt que l’usage supposé — les services d’accès distant activés « pour un test » et jamais désactivés sont une découverte banale en audit.
L’échéance du 14 août 2026 s’applique-t-elle à une entreprise française ?
Non. Cette date engage les agences fédérales civiles américaines au titre du catalogue KEV de la CISA et n’a aucune portée juridique en France. Elle reste néanmoins le meilleur signal public dont vous disposez sur la réalité de l’exploitation : une inscription au KEV signifie qu’une autorité a constaté une exploitation active. Utilisez-la comme critère de priorisation, pas comme obligation réglementaire.
Existe-t-il un contournement en attendant la fenêtre de maintenance ?
L’avis indique qu’il n’y a pas de contournement disponible. Vous pouvez réduire l’exposition — restriction des adresses sources autorisées à joindre le service, surveillance renforcée des redémarrages, préparation d’un mode dégradé — mais aucune de ces mesures ne corrige la vulnérabilité. Elles achètent du temps ; elles ne remplacent pas le correctif.
Comment savoir si nous avons déjà été visés ?
L’avis précise qu’aucun indicateur de compromission spécifique n’est publié, donc il n’existe pas de signature à rechercher sur l’équipement. Vos seules pistes sont vos propres journaux : redémarrages inexpliqués, coupures VPN brèves mises sur le compte du réseau, tickets utilisateurs classés sans suite. Si ces journaux ne sont pas centralisés et conservés hors de l’équipement, l’analyse rétrospective n’est pas possible.
Le prochain avis critique tombera dans quelques semaines
Inventaire des équipements exposés, politique de mise à jour écrite, fenêtre de maintenance négociée à l’avance. Trois livrables qui transforment une nuit blanche en intervention de vingt minutes.
Discutons-enSources : avis de sécurité Cisco relatif à CVE-2026-20349 et couverture de Help Net Security du 13 août 2026 (« Cisco fixes vulnerability exploited to DoS its firewalls ») ; catalogue des vulnérabilités activement exploitées de la CISA, échéance de remédiation fédérale au 14 août 2026. Les recommandations opérationnelles reflètent la position de WebGuard Agency et n’engagent que nous.