Contournement SAML du SSLVPN SonicWall, exploité dans la nature (CVE-2026-19868)

En bref

• Une faille du SSLVPN de SonicOS permet à un compte disposant d'identifiants valides pour une autre méthode d'authentification de contourner la politique SAML. L'authentification multifacteur appliquée par SAML est aussi contournée. SonicWall a publié CVE-2026-19868 le 6 novembre 2026.
• Les pare-feu Gen7 en 7.3.3-7015 ou antérieur et les pare-feu Gen8 en 8.2.2-8015 ou antérieur sont concernés lorsque SAML est activé pour les connexions SSLVPN. Les versions corrigées sont 7.3.4-7013 et 8.2.3-8015.
• Notée CVSS v3.1 7,1 High par SonicWall, 7,5 dans l'ADP de la CISA. SonicWall a enquêté sur une exploitation potentielle. La CISA a ajouté la CVE au catalogue Known Exploited Vulnerabilities le 6 novembre 2026. L'échéance est le 20 novembre 2026.
• Mettez à niveau vers 7.3.4-7013 ou 8.2.3-8015 ; SonicWall ne liste aucun contournement. En attendant, vérifiez quels comptes peuvent s'authentifier sur le SSLVPN par une méthode autre que SAML, comme l'explique « Comment corriger ? ».

Suis-je concerné ?

Toutes ces conditions doivent être réunies pour être exposé à CVE-2026-19868 :

• Le pare-feu exécute SonicOS Gen7 en 7.3.3-7015 ou antérieur, ou Gen8 en 8.2.2-8015 ou antérieur.
• Le service SSLVPN est activé et joignable depuis le réseau où opère l'attaquant.
• SAML est activé pour les connexions SSLVPN. SonicWall précise que la faille « ONLY impacts the SonicOS SSLVPN interface or service if SAML is enabled for SSLVPN logins ».
• Au moins un compte peut s'authentifier par une autre méthode. L'attaquant a besoin d'identifiants valides pour ce compte, comme l'indique l'avis.

L'avis couvre deux gammes et une longue liste de modèles.

• Matériel Gen7 : TZ 270, 370, 470, 570 et 670 ; NSa 2700 à 6700 ; NSsp 10700 à 15700.
• NSv Gen7 : NSv 270, 470 et 870.
• Matériel Gen8 : TZ 80, 280, 380, 480, 580 et 680 ; NSa 2800 à 5800.
• NSv Gen8 : NSv XS, S, M et L.

L'avis corrige aussi six autres failles SonicOS dans les mêmes versions. Cet article traite de CVE-2026-19868, la seule des sept que la CISA a ajoutée au catalogue KEV.

La faille exploitée n'est pas la mieux notée de son propre avis. Deux failles de l'interface de gestion sont notées 8,8 et le débordement de tas du SSLVPN est noté 7,5. C'est l'inscription au KEV, et non le score, qui la rend urgente.

Vérifiez d'abord le micrologiciel en cours d'exécution. À la ligne de commande SonicOS, show version affiche la chaîne de version. Dans l'interface web, System > Status affiche la même chaîne. La version doit être comparée à la version corrigée de la gamme, pas à la dernière version publiée en général.

Vérifiez ensuite la configuration du SSLVPN. Dans les paramètres d'authentification du SSLVPN, confirmez si SAML est activé pour les connexions VPN. S'il ne l'est pas, cette CVE ne s'applique pas à cette configuration, même sur une version concernée. Les six autres failles de l'avis ont leurs propres conditions, donc une mise à niveau reste justifiée.

Dressez enfin la liste des comptes et des méthodes d'authentification acceptés par le SSLVPN. L'avis ne précise pas quelles méthodes alternatives atteignent la faille. Considérez toute méthode activée autre que SAML comme un chemin possible, et tout compte qui peut l'utiliser comme une source possible d'identifiants valides.

Comment corriger ?

1. Sauvegardez la configuration du pare-feu et notez la version actuelle du micrologiciel, afin de pouvoir revenir en arrière.
2. Téléchargez la version corrigée de la gamme depuis MySonicWall : 7.3.4-7013 ou ultérieure pour Gen7, et 8.2.3-8015 ou ultérieure pour Gen8. SonicWall publie les plateformes et versions corrigées dans la table Fixed Software de l'avis.
3. Installez le micrologiciel sur chaque pare-feu et confirmez la nouvelle version après le redémarrage. Pour une appliance virtuelle NSv, mettez-la à niveau ou redéployez-la avec la même version corrigée.
4. Confirmez que le SSLVPN utilise toujours SAML pour les comptes qui doivent l'utiliser, et qu'aucune méthode alternative non voulue ne reste activée.

La même mise à niveau corrige six failles compagnes dans SNWLID-2026-0014.

• Deux failles de l'interface de gestion notées 8,8, CVE-2026-107155 et CVE-2026-107154.
• Un débordement de tas avant authentification dans le service SSL-VPN noté 7,5, CVE-2026-82308.
• Deux débordements avant authentification dans le client TACACS+ notés 5,9, CVE-2026-77708 et CVE-2026-77709.
• Une faille de hachage de mot de passe faible sur les appliances virtuelles notée 5,2, CVE-2026-19703.

Seule CVE-2026-19868 a un signalement d'exploitation et une inscription au KEV.

SonicWall ne liste aucun contournement. Les étapes de cette section réduisent l'exposition jusqu'à la mise à niveau, mais elles ne corrigent pas la faille d'application de l'authentification.

1. Supprimez ou désactivez les comptes SSLVPN qui peuvent s'authentifier par une méthode autre que SAML. Cela retire l'accès VPN de ces utilisateurs ; gardez donc un chemin d'administration qui ne dépend pas du SSLVPN.
2. Limitez le SSLVPN aux adresses sources que vous contrôlez, par exemple une plage de sortie d'entreprise ou un réseau d'administration. Cela réduit la population qui peut atteindre la page de connexion, mais la faille reste joignable depuis toute adresse autorisée.
3. Examinez les journaux d'authentification du SSLVPN pour repérer les connexions réussies qui ont utilisé une méthode autre que SAML. Une connexion pour un compte censé utiliser SAML est une piste, pas une preuve de compromission.

Aucune de ces étapes ne remplace la version corrigée. La remédiation du fournisseur est la mise à niveau du micrologiciel.

Quelle est la cause racine ?

La passerelle SSLVPN n'applique pas la politique SAML à un compte qui peut s'authentifier par une autre méthode. Une telle connexion aboutit sans l'assertion SAML. Elle saute aussi l'authentification multifacteur que SAML applique.

SonicOS peut authentifier les utilisateurs du SSLVPN par plusieurs méthodes. Un administrateur qui active SAML s'attend à ce que la passerelle exige le flux SAML et l'authentification multifacteur du fournisseur d'identité pour chaque connexion VPN. La faille réside dans cette application.

Lorsqu'un compte présente des identifiants valides pour une autre méthode, la passerelle accepte cette méthode comme suffisante. Le contrôle SAML n'est pas appliqué, donc la connexion se poursuit avec la seule méthode alternative.

SonicWall attribue CWE-308, Use of Single-Factor Authentication, à la faille. Cette faiblesse décrit le résultat plutôt qu'une ligne de code. Un seul facteur suffit à la passerelle : l'identifiant de la méthode alternative. Cela suffit même si l'administrateur a configuré SAML et son authentification multifacteur. La portée CVSS est modifiée, car le contournement franchit la frontière d'authentification configurée par l'administrateur.

SonicWall ne publie ni code source ni correctif diff pour SonicOS. L'avis nomme la condition préalable, les versions concernées et l'impact. Il ne nomme pas le chemin de code, la méthode alternative, ni la séquence de requêtes.

La branche exacte du code d'authentification ne peut donc pas être reconstituée à partir des informations publiques. Ce qui est public, c'est la frontière de la faille : SAML doit être activé pour les connexions SSLVPN, et l'attaquant doit détenir des identifiants valides pour une méthode alternative.

Comment la faille est-elle exploitée ?

L'attaque transforme un mot de passe valide pour une méthode alternative en session VPN qui ne satisfait jamais la politique SAML ni son authentification multifacteur. L'avis décrit le mécanisme mais ne publie aucune séquence de requêtes ; les étapes de cette liste suivent donc sa formulation et l'enregistrement CVE :

1. L'attaquant trouve un SSLVPN SonicOS exposé sur Internet avec SAML activé pour les connexions VPN.
2. L'attaquant détient des identifiants valides pour un compte qui peut s'authentifier par une autre méthode. L'avis ne précise pas quelles méthodes sont acceptées sur une configuration vulnérable.
3. L'attaquant s'authentifie sur le SSLVPN par cette méthode alternative au lieu du flux SAML.
4. La passerelle accepte la connexion sans exiger l'assertion SAML. L'authentification multifacteur appliquée par SAML ne s'exécute pas, car la session n'atteint jamais l'étape SAML.
5. L'attaquant obtient une session VPN avec les permissions du compte et peut atteindre les ressources internes que ce compte est autorisé à joindre.
6. La session s'utilise comme toute autre session VPN, avec la journalisation et les contrôles d'accès qui s'appliquent à ce compte.

Il s'agit d'un contournement de l'authentification multifacteur pour un mot de passe volé, réutilisé ou obtenu autrement. Ce n'est pas une entrée non authentifiée dans le pare-feu. L'attaquant a toujours besoin d'un identifiant valide pour un compte qui peut utiliser une méthode alternative.

Cette distinction compte pour évaluer l'exposition : la population à risque est celle de tous les comptes qui peuvent contourner la politique SAML, pas celle de tous les internautes.

La CISA a ajouté la CVE au KEV le 6 novembre 2026, ce qui enregistre une exploitation active. SonicWall indique avoir enquêté sur un signalement d'exploitation potentielle. Aucune des deux sources ne nomme une victime, une date, un acteur ou une adresse source. Aucune preuve de concept ni séquence de requêtes n'est publique, donc ces étapes ne peuvent pas être rejouées à partir des seules informations publiques.

Comment se déroule l'attaque ?

Un mot de passe valide pour une méthode alternative atteint le SSLVPN. La passerelle saute alors la politique SAML et son authentification multifacteur, et l'attaquant obtient une session VPN avec l'accès de ce compte.

Que peut faire un attaquant ?

L'attaquant obtient une session VPN avec le compte dont les identifiants de méthode alternative ont été utilisés, avec les permissions de ce compte. L'impact direct est l'accès aux réseaux et services internes que le compte est autorisé à joindre.

SonicWall évalue CVE-2026-19868 CVSS v3.1 7,1 High, CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:L/A:N. Le bloc ADP de la CISA porte 7,5, CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:L/A:N. Les deux vecteurs diffèrent sur les privilèges requis : le fournisseur suppose un compte valide, le bloc ADP de la CISA non.

Tous deux enregistrent un impact élevé sur la confidentialité, faible sur l'intégrité et nul sur la disponibilité. Cela correspond à un point d'appui VPN orienté lecture, pas à une faille d'exécution de code.

Toutes les conditions de « Suis-je concerné ? » s'appliquent intégralement :

• Le pare-feu est une version Gen7 ou Gen8 concernée.
• Le SSLVPN est joignable depuis le réseau de l'attaquant.
• SAML est activé pour les connexions SSLVPN.
• L'attaquant détient des identifiants valides pour un compte qui peut s'authentifier par une méthode alternative.

L'avis ne décrit aucun moyen de dépasser l'autorisation VPN du compte par cette faille. Un compte à faibles privilèges donne un tunnel à faibles privilèges ; un compte privilégié ou largement autorisé donne beaucoup plus. L'avis ne décrit ni création de compte, ni exécution de code, ni élévation de privilèges sur le pare-feu, et l'enregistrement CVE non plus.

Considérez ces impacts comme hors du champ de cette CVE, et non comme démontrés.

L'exposition est la plus forte là où le SSLVPN constitue la frontière d'authentification multifacteur pour une population. Tout mot de passe qui aurait été bloqué par l'authentification multifacteur SAML suffit alors à ouvrir une session VPN. C'est le scénario que l'inscription au KEV rend urgent, et c'est pourquoi la version corrigée, et non une règle de détection, est le contrôle principal.

Pourquoi le correctif fonctionne-t-il ?

Les versions corrigées ferment la lacune d'application : une connexion par une méthode alternative ne peut plus satisfaire le SSLVPN lorsque SAML est configuré pour les connexions VPN. SonicWall ne publie ni la modification de code ni un correctif diff, donc l'exhaustivité du correctif repose sur la déclaration du fournisseur selon laquelle 7.3.4-7013 et 8.2.3-8015 le contiennent.

L'avis liste les mêmes versions corrigées pour l'ensemble du lot de sept CVE, et il ne liste aucun contournement. La mise à niveau est donc la seule remédiation prise en charge par le fournisseur. Les étapes opérationnelles de « Comment corriger ? » réduisent qui peut atteindre le chemin alternatif, mais elles laissent la faille d'application en place.

Si vous exploitez une appliance virtuelle, confirmez que l'image NSv est reconstruite ou mise à niveau vers la version corrigée. Une sauvegarde de configuration restaurée sur une ancienne image réintroduit la faille.

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

SonicWall n'a publié ni indicateurs de compromission, ni nombre de victimes, ni signature de requête. Les vérifications de cette section cherchent l'effet de la faille plutôt qu'une charge utile connue.

Commencez par les enregistrements d'authentification du SSLVPN sur le pare-feu ou dans le collecteur syslog. Recherchez les connexions réussies de comptes censés utiliser SAML, et comparez la méthode d'authentification enregistrée pour chaque connexion avec celle que le compte est censé utiliser. Une connexion réussie pour un compte réservé à SAML qui enregistre une autre méthode est le schéma que cette faille produirait.

Examinez ensuite ce que la session a fait. Comparez les adresses sources et les heures de ces connexions au schéma habituel du compte. Recherchez des hôtes ou services internes que le compte ne joint pas d'ordinaire, et des sessions commencées hors des heures de travail ou du pays du titulaire du compte.

Vérifiez l'inventaire des comptes pour les changements de la même période. De nouveaux comptes locaux, des méthodes d'authentification alternatives activées récemment et de nouvelles autorisations SSLVPN méritent tous une enquête.

L'inscription au KEV renvoie aux exigences de triage forensique de la CISA au titre de la directive opérationnelle liante 26-04. Cette recommandation est la référence pour les preuves à conserver, même si vous n'êtes pas une agence fédérale.

Une tentative qui échoue ne laisse pas de trace particulière. Une connexion réussie peut ressembler à une connexion normale dans un journal qui n'enregistre pas la méthode d'authentification. Si vous ne pouvez pas exclure une connexion, considérez le compte comme compromis. Réinitialisez ses identifiants et examinez ce qu'il pouvait atteindre. Reconstruisez le pare-feu à partir d'une configuration saine si l'équipement lui-même est suspect.

Chronologie

• 2026-11-06 : SonicWall publie SNWLID-2026-0014 et CVE-2026-19868. L'avis indique que le PSIRT de SonicWall a enquêté sur un signalement d'exploitation potentielle.
• 2026-11-06 : la CISA ajoute CVE-2026-19868 au catalogue Known Exploited Vulnerabilities, avec une échéance fédérale au 20 novembre 2026.
• 2026-11-20 : échéance fédérale de remédiation pour CVE-2026-19868.

FAQ

Cette faille concerne-t-elle les appliances SonicWall SMA1000 ?

Non. CVE-2026-19868 est une faille SonicOS des gammes de pare-feu Gen7 et Gen8 et des NSv. Le SMA1000 est une gamme d'accès distant distincte, et ses problèmes de 2026 ont leurs propres avis et correctifs. Un parc SonicWall peut contenir les deux, donc vérifiez chaque produit par rapport à son propre avis, et non par rapport à ce tableau de versions.

Un attaquant peut-il l'exploiter sans aucun identifiant ?

Non. L'avis exige des identifiants valides pour une méthode d'authentification alternative. La faille retire l'étape SAML et multifacteur pour ce compte ; elle ne retire pas l'étape du mot de passe. Un internaute sans compte sur le pare-feu ou sur ses sources d'identité ne peut pas emprunter ce chemin.

Est-elle exploitable lorsque SAML n'est pas activé ?

Non. SonicWall limite la faille aux services SSLVPN où SAML est activé pour les connexions VPN. Cela ne rend pas les six autres failles de l'avis inoffensives, et une version concernée doit tout de même être mise à niveau.

Existe-t-il un contournement si je ne peux pas mettre à niveau aujourd'hui ?

SonicWall n'en liste aucun. Retirer les comptes à méthode alternative du SSLVPN et restreindre le service à des adresses sources de confiance réduit l'exposition, mais ne corrige pas la lacune d'application. Le micrologiciel corrigé est la remédiation.

CVE-2026-19868 est-elle au catalogue KEV de la CISA ?

Oui. La CISA l'a ajoutée le 6 novembre 2026 avec une échéance fédérale au 20 novembre 2026. Cette inscription enregistre une exploitation active, et c'est pourquoi cet article commence par la mise à niveau plutôt que par la détection.

Qu'en est-il des six autres CVE du même avis ?

Elles sont corrigées dans les mêmes versions.

• Deux failles de l'interface de gestion sont notées 8,8.
• Le débordement de tas du SSL-VPN est noté 7,5.
• Les deux débordements TACACS+ sont notés 5,9 chacun.
• La faille de hachage de mot de passe faible est notée 5,2.

Seule CVE-2026-19868 a un signalement d'exploitation et une inscription au KEV.

Trouver les passerelles SSLVPN SonicWall exposées avec Ostorlab

La découverte de surface d'attaque d'Ostorlab inventorie les hôtes exposés sur Internet et les services qu'ils exposent. Utilisez-la pour lister les passerelles SonicWall qui répondent sur leurs interfaces de gestion et VPN, puis vérifiez leur micrologiciel.

Références

• Avis SonicWall PSIRT SNWLID-2026-0014, « SonicWall SonicOS Affected By Multiple Vulnerabilities », publié le 6 novembre 2026, avec les plateformes concernées, les versions corrigées, les sept identifiants CVE et la déclaration d'exploitation : https://psirt.global.sonicwall.com/vuln-detail/SNWLID-2026-0014 (vérifié le 7 novembre 2026)
• Enregistrement CVE-2026-19868, CNA SonicWall, publié le 6 novembre 2026, CWE-308, les versions concernées et le bloc métrique et KEV de l'ADP de la CISA : https://www.cve.org/CVERecord?id=CVE-2026-19868 (vérifié le 7 novembre 2026)
• Catalogue Known Exploited Vulnerabilities de la CISA, CVE-2026-19868 ajoutée le 6 novembre 2026 avec une échéance au 20 novembre 2026 : https://www.cisa.gov/known-exploited-vulnerabilities-catalog (vérifié le 7 novembre 2026)
• BleepingComputer, « SonicWall warns of new SSL-VPN MFA bypass flaw exploited in attacks », 6 novembre 2026, la déclaration d'exploitation du fournisseur, les versions corrigées et le crédit au découvreur : https://www.bleepingcomputer.com/news/security/sonicwall-warns-of-new-ssl-vpn-mfa-bypass-flaw-exploited-in-attacks/ (vérifié le 7 novembre 2026)
• CWE-308, Use of Single-Factor Authentication, la faiblesse attribuée par SonicWall à la faille : https://cwe.mitre.org/data/definitions/308.html (vérifié le 7 novembre 2026)
• Directive opérationnelle liante 26-04 de la CISA, les exigences de triage forensique citées par l'inscription au KEV : https://www.cisa.gov/news-events/directives/bod-26-04-prioritizing-security-updates-based-risk (vérifié le 7 novembre 2026)