En bref. La CVE-2026-19868, corrigée par SonicWall le 6 novembre 2026, permet à un utilisateur disposant d'identifiants valides pour une autre méthode d'authentification de contourner l'authentification SAML du VPN SSL de SonicOS, y compris l'authentification multifacteur imposée par SAML. SonicWall a enquêté sur un signalement d'exploitation et la CISA a ajouté la faille à son catalogue des vulnérabilités exploitées. Pour une entité soumise à NIS 2, cet épisode touche trois obligations de la directive : la gestion des vulnérabilités, l'authentification multifacteur (article 21) et, en cas d'incident important, la notification en 24 heures (article 23).
Ce qui s'est passé
Le 6 novembre 2026, SonicWall publie un avis qui corrige sept vulnérabilités de SonicOS, le système d'exploitation de ses pare-feu. L'une d'elles, CVE-2026-19868, est décrite par l'éditeur comme une faille d'application de l'authentification dans le service VPN SSL (réseau privé virtuel chiffré) : un utilisateur disposant d'identifiants valides pour une méthode d'authentification alternative peut contourner les contrôles d'authentification SAML (Security Assertion Markup Language, le protocole de fédération d'identité souvent utilisé pour l'authentification unique). Selon SonicWall, l'exploitation peut aussi contourner l'authentification multifacteur (MFA) imposée par SAML.
Points clés, d'après BleepingComputer et SecurityWeek (7 novembre 2026) :
- Score CVSS de 7,1, sévérité élevée.
- Seuls les services VPN SSL configurés avec l'authentification SAML sont exposés.
- Exploitation : la PSIRT de SonicWall (son équipe de réponse aux vulnérabilités produit) indique avoir enquêté sur un signalement d'exploitation potentielle. La CISA (agence américaine de cybersécurité) a ajouté la faille à son catalogue KEV (Known Exploited Vulnerabilities) le jour même, et impose aux agences fédérales américaines de la corriger avant le 20 novembre 2026. Ni SonicWall ni la CISA n'ont donné de détails sur les attaques, et on ne sait pas si la faille a été exploitée avant la publication du correctif.
- Versions touchées : Gen7 (TZ, NSa, NSsp, NSv) en SonicOS 7.3.3-7015 ou antérieure ; Gen8 (TZ, NSa, NSv) en 8.2.2-8015 ou antérieure.
- Correctifs : SonicOS 7.3.4-7013 et 8.2.3-8015. SonicWall indique qu'aucun contournement n'existe.
Le même avis corrige six autres failles, non signalées comme exploitées : deux failles de l'interface d'administration notées 8,8, qu'un attaquant distant peut exploiter sans se connecter dans certaines conditions ; trois dépassements de mémoire tampon avant authentification dans le VPN SSL et le client TACACS+, qui permettent un déni de service ; un hachage de mot de passe faible sur les appliances virtuelles.
SecurityWeek rappelle que le catalogue KEV de la CISA compte déjà 20 failles SonicWall.
Comment fonctionne ce type de contournement (principe)
La MFA imposée par SAML repose sur un enchaînement : le VPN délègue l'authentification à un fournisseur d'identité, qui applique le second facteur, puis renvoie une assertion au VPN. La sécurité suppose que le VPN n'accepte pas d'autre chemin pour les comptes soumis à cette politique.
La description de SonicWall indique que ce verrou n'était pas appliqué : des identifiants valides pour une méthode alternative permettaient de passer à côté du contrôle SAML. En pratique, cela signifie qu'un mot de passe volé, réutilisé ou issu d'un ancien mode d'authentification local peut suffire là où l'organisation croyait exiger un second facteur. SonicWall n'a pas publié davantage de détails techniques.
Qui est concerné
- Toute organisation qui utilise des pare-feu SonicWall Gen7 ou Gen8 avec le VPN SSL et l'authentification SAML, dans les versions listées.
- Au titre de NIS 2 : les entités essentielles et importantes au sens de la directive (UE) 2022/2555, dans les secteurs listés en annexes I et II, selon les règles de la loi nationale de transposition de leur État membre.
Ce que NIS 2 impose
La directive devait être transposée au plus tard le 17 octobre 2024, avec une application à partir du 18 octobre 2024 (article 41). Les obligations ci-dessous s'appliquent aux entités via le droit national ; les extraits cités sont ceux du texte officiel de la directive.
Article 21 : les mesures de gestion des risques
L'article 21, paragraphe 2, liste les mesures minimales. Trois points sont directement en jeu ici :
- point e) : « la sécurité de l'acquisition, du développement et de la maintenance des réseaux et des systèmes d'information, y compris le traitement et la divulgation des vulnérabilités ». Appliquer un correctif sur une faille exploitée d'un équipement exposé relève de cette mesure.
- point j) : « l'utilisation de solutions d'authentification à plusieurs facteurs ou d'authentification continue [...] selon les besoins ». Une MFA contournable ne remplit plus son rôle tant que le correctif n'est pas appliqué.
- point d) : « la sécurité de la chaîne d'approvisionnement, y compris les aspects liés à la sécurité concernant les relations entre chaque entité et ses fournisseurs ». Le paragraphe 3 demande de tenir compte « des vulnérabilités propres à chaque fournisseur » et de « la qualité globale des produits et des pratiques de cybersécurité » des fournisseurs.
L'article 21, paragraphe 4, ajoute que lorsqu'une entité constate qu'elle ne se conforme pas aux mesures du paragraphe 2, elle prend « sans retard injustifié, toutes les mesures correctives nécessaires appropriées et proportionnées ».
L'article 20, paragraphe 1, prévoit que les organes de direction approuvent ces mesures, supervisent leur mise en œuvre et peuvent être tenus responsables de la violation de l'article 21.
Article 23 : la notification des incidents importants
Si la faille a été exploitée chez vous, l'article 23 peut s'appliquer. Un incident est important, selon le paragraphe 3, s'il « a causé ou est susceptible de causer une perturbation opérationnelle grave des services ou des pertes financières pour l'entité concernée », ou s'il « a affecté ou est susceptible d'affecter d'autres personnes physiques ou morales en causant des dommages matériels, corporels ou moraux considérables ».
Le paragraphe 4 fixe les échéances vis-à-vis du CSIRT (centre de réponse aux incidents de sécurité) ou de l'autorité compétente :
- a) une alerte précoce « dans les 24 heures après avoir eu connaissance de l'incident important » ;
- b) une notification d'incident « dans les 72 heures », avec une évaluation initiale et, si disponibles, des indicateurs de compromission ;
- c) un rapport intermédiaire à la demande du CSIRT ou de l'autorité ;
- d) un rapport final « au plus tard un mois après la présentation de la notification d'incident ».
La qualification d'un incident important dépend de son impact constaté ou probable, au regard de ces deux critères. Elle doit être faite et documentée.
Se mettre en conformité : la méthode
Dans les 24 heures
- Inventorier les pare-feu SonicWall, leur génération, leur version SonicOS et l'activation du VPN SSL avec SAML.
- Appliquer SonicOS 7.3.4-7013 (Gen7) ou 8.2.3-8015 (Gen8). SonicWall n'indique aucun contournement : le correctif est la seule mesure de l'éditeur.
- Restreindre l'accès à l'interface d'administration aux réseaux d'administration, compte tenu des deux failles notées 8,8 corrigées dans le même avis. C'est une bonne pratique générale, pas une consigne de l'avis.
Dans la semaine
- Rechercher des traces : connexions VPN réussies sur des comptes soumis à SAML sans assertion correspondante côté fournisseur d'identité. Comparez les journaux du pare-feu et ceux du fournisseur d'identité sur la période précédant le correctif.
- Supprimer les méthodes d'authentification alternatives inutiles (comptes locaux, anciens annuaires) sur les équipements où SAML est la politique. Moins il existe de chemins, moins un contournement a de prise.
- Qualifier tout événement suspect au regard de l'article 23, paragraphe 3, et déclencher si besoin l'alerte précoce en 24 heures.
Dans le mois
- Documenter la décision et le délai de correction pour démontrer l'application de l'article 21, paragraphe 4.
- Revoir le fournisseur au titre de l'article 21, paragraphe 3 : historique des failles exploitées, délais de correctif, qualité des avis.
- Rendre compte à la direction, qui approuve et supervise les mesures selon l'article 20.
Méthode de vérification : depuis un compte de test soumis à la politique SAML, tentez une connexion VPN par une autre méthode d'authentification après correctif. Le refus doit être constaté et journalisé. Mesurez aussi le délai entre la publication de l'avis et l'application du correctif sur tous les équipements : c'est l'indicateur à présenter en audit.
FAQ
Quelles versions de SonicOS corrigent CVE-2026-19868 ?
SonicOS 7.3.4-7013 pour la Gen7 et 8.2.3-8015 pour la Gen8. Les versions 7.3.3-7015 et 8.2.2-8015 ou antérieures sont touchées.
Mon pare-feu est-il vulnérable si je n'utilise pas SAML ?
Selon SonicWall, cette faille ne touche que le VPN SSL configuré avec l'authentification SAML. Les six autres failles du même avis ont d'autres conditions, et la mise à jour reste nécessaire.
NIS 2 oblige-t-elle à utiliser l'authentification multifacteur ?
L'article 21, paragraphe 2, point j), inclut parmi les mesures minimales « l'utilisation de solutions d'authentification à plusieurs facteurs ou d'authentification continue », « selon les besoins ». Le niveau exigé dépend de l'analyse de risque et de la loi nationale de transposition.
Faut-il notifier une vulnérabilité corrigée sans exploitation constatée ?
L'article 23 vise les incidents importants, pas les vulnérabilités. Une faille corrigée sans incident ne déclenche pas de notification au titre de cet article. En revanche, une exploitation constatée doit être qualifiée selon les critères du paragraphe 3.
Sources
- BleepingComputer, SonicWall warns of new SSL-VPN MFA bypass flaw exploited in attacks, 7 novembre 2026 : https://www.bleepingcomputer.com/news/security/sonicwall-warns-of-new-ssl-vpn-mfa-bypass-flaw-exploited-in-attacks
- SecurityWeek, SonicWall Patches Exploited SonicOS Vulnerability That Weakens VPN Logins, 7 novembre 2026 : https://www.securityweek.com/sonicwall-patches-exploited-sonicos-bug-that-weakens-vpn-logins
- Directive (UE) 2022/2555 (NIS 2), texte officiel en français : https://eur-lex.europa.eu/legal-content/FR/TXT/HTML/?uri=CELEX:32022L2555
Pour cadrer vos mesures de l'article 21 et votre procédure de notification, WeeSec accompagne les entités concernées sur NIS 2.