Certains déploiements SSL VPN de SonicOS peuvent accepter d’autres identifiants sans appliquer le parcours d’authentification SAML qu’ils exigent. La vulnérabilité figure dans le catalogue Known Exploited Vulnerabilities de la CISA. SonicWall répertorie des firmwares Gen7 et Gen8 corrigés.
Informations à jour au 9 novembre 2026, y compris la révision de l’avis de SonicWall publiée ce jour-là.
SonicWall a divulgué CVE-2026-19868, une faille dans la manière dont certains déploiements SSL VPN de SonicOS appliquent l’authentification lorsque SAML est configuré. Le SSL VPN est le service d’accès à distance par lequel le personnel se connecte au réseau de l’entreprise depuis l’extérieur. Une personne disposant d’identifiants valides pour une autre méthode d’authentification pourrait être en mesure d’accéder au VPN sans passer par le parcours de connexion SAML prévu. Si la politique d’authentification multifacteur (MFA, multi-factor authentication) de l’organisation est appliquée par SAML, cette exigence de MFA pourrait elle aussi être contournée.
Il ne s’agit pas d’une vulnérabilité permettant de se connecter sans identifiants. Elle concerne la manière dont un VPN impose sa méthode d’authentification obligatoire lorsqu’une autre méthode valide existe. La CISA a ajouté la vulnérabilité à son catalogue Known Exploited Vulnerabilities le 6 novembre 2026. SonicWall répertorie des firmwares corrigés pour les appareils Gen7 et Gen8 concernés, ses septième et huitième générations de pare-feu.
L’essentiel pour les administrateurs
| Question | Ce que disent les sources |
|---|---|
| Vulnérabilité | CVE-2026-19868, SonicWall SonicOS SSL VPN |
| Ce qui est contourné | L’authentification SAML et toute MFA imposée par SAML |
| Prérequis pour l’attaquant | Des identifiants valides pour une autre méthode d’authentification |
| Exposition | Versions concernées de SonicOS Gen7/Gen8 avec SAML activé pour le SSL VPN |
| Exploitation | Le PSIRT de SonicWall a enquêté sur un signalement d’exploitation potentielle, et la CISA a ajouté la vulnérabilité à son catalogue KEV le 6 novembre 2026 |
| Gen7 corrigé | SonicOS 7.3.4-7013 ou ultérieur, selon SonicWall |
| Gen8 corrigé | SonicOS 8.2.3-8015 ou ultérieur, selon SonicWall |
| Action des administrateurs | Vérifier la configuration et le build, installer un firmware pris en charge, valider l’authentification, évaluer les accès antérieurs |
Sources : avis PSIRT de SonicWall SNWLID-2026-0014, avis de SonicWall sur les firmwares Gen7/Gen8 et CISA KEV.
Ce que change la faille d’authentification
De nombreuses entreprises rattachent les connexions VPN d’accès à distance à un fournisseur d’identité (identity provider) central au moyen de SAML, abréviation de Security Assertion Markup Language. Au lieu que le pare-feu décide seul si un mot de passe suffit, c’est le fournisseur d’identité qui effectue les vérifications requises, qui peuvent inclure la MFA et des règles d’accès conditionnel.
Par conception, une session VPN ne devrait démarrer qu’une fois la connexion SAML requise menée à bien. Une deuxième méthode d’authentification ne doit pas devenir discrètement une voie plus facile vers le même accès.
L’entrée de la CISA consacrée à CVE-2026-19868 décrit précisément cette situation : une personne disposant d’identifiants valides pour une autre méthode contourne les contrôles d’authentification SAML, y compris potentiellement la MFA imposée par SAML.
Un fournisseur d’identité pourrait rejeter à juste titre une connexion dépourvue de MFA, alors que le pare-feu accepterait quand même une session par un autre chemin d’identifiants. La défaillance porte sur l’application de la politique d’authentification VPN prévue à l’ensemble des méthodes de connexion disponibles. Elle ne prouve pas que le fournisseur d’identité lui-même a été compromis, ni que n’importe quel utilisateur peut entrer sans identifiants.
Dans l’avis examiné pour cette publication, SonicWall n’a pas divulgué publiquement de séquence d’exploitation complète ni l’intégralité du défaut d’implémentation, et cet article ne fait aucune hypothèse à leur sujet. La description de la vulnérabilité ne nomme pas les autres méthodes, mais la solution de contournement (workaround) de SonicWall mentionne les serveurs d’authentification LDAP, RADIUS et TACACS+ configurés sur le pare-feu, ce qui laisse penser qu’il s’agit de ce type d’identifiants alternatifs.
Firmwares concernés et condition de configuration
L’avis de sécurité de SonicWall de novembre 2026 fournit la matrice suivante des firmwares Gen7/Gen8 :
| Famille d’appareils | Builds concernés selon le fournisseur | Build corrigé selon le fournisseur |
|---|---|---|
| Gen7 physiques et virtuels | SonicOS 7.3.3-7015 et antérieurs | SonicOS 7.3.4-7013 et ultérieurs |
| Gen8 physiques et virtuels | SonicOS 8.2.2-8015 et antérieurs | SonicOS 8.2.3-8015 et ultérieurs |
L’avis traite de plusieurs vulnérabilités de SonicOS, c’est pourquoi la matrice des versions doit être rapprochée de la fiche PSIRT propre à la CVE. Dans sa révision publiée le 9 novembre 2026, cette fiche indique les mêmes builds concernés et les mêmes builds corrigés pour CVE-2026-19868. SonicWall précise que cette vulnérabilité n’affecte le service SSL VPN que si SAML est activé pour les connexions SSL VPN, ce qui constitue la condition déterminante.
Un avis gouvernemental du Centre canadien pour la cybersécurité (Canadian Centre for Cyber Security) indique comme concernées les versions Gen8 antérieures à 8.2.2-8015, ce qui exclurait la version 8.2.2-8015 elle-même. SonicWall indique 8.2.2-8015 et les versions antérieures comme concernées, à la fois dans son avis sur les firmwares et dans son avis propre à la CVE. Ce sont donc les documents du fournisseur qui font foi pour la version cible de la mise à niveau, et la version 8.2.2-8015 doit être considérée comme concernée. Les administrateurs doivent aussi vérifier la compatibilité des modèles et si un build de maintenance plus récent et pris en charge a remplacé le correctif indiqué.
Le matériel Gen6 et plus ancien se situe en dehors du chemin de mise à niveau Gen7/Gen8 décrit dans l’avis de SonicWall et n’est plus pris en charge (end-of-support). On ne peut pas supposer qu’un pare-feu non pris en charge est protégé par une version de firmware destinée à une autre génération.
Pourquoi l’inscription par la CISA parmi les vulnérabilités exploitées est importante
La CISA a ajouté CVE-2026-19868 au KEV le 6 novembre 2026. Le KEV a vocation à recenser les vulnérabilités pour lesquelles il existe des preuves d’exploitation réelle, ce qui en fait un outil utile pour prioriser les correctifs. L’avis de SonicWall indique que son PSIRT a enquêté sur un signalement faisant état d’une exploitation potentielle, et le Centre canadien pour la cybersécurité indique que SonicWall signale l’exploitation de la vulnérabilité.
L’inscription publique ne fournit pas de nombre d’organisations compromises, ni d’identité d’attaquant vérifiée, ni de récit détaillé de chaque incident observé. Tant que des éléments fiables ne sont pas disponibles, ces détails restent inconnus.
L’entrée indique le 20 novembre 2026 comme date limite de correction fédérale. Cette date s’applique dans le cadre des obligations fédérales américaines concernées. Ce n’est pas automatiquement une échéance réglementaire pour toute entreprise privée, mais les déploiements VPN concernés et accessibles depuis Internet devraient tout de même être corrigés rapidement.
Source : CISA Known Exploited Vulnerabilities Catalog.
Correction et vérification
Le correctif principal consiste à mettre à niveau le pare-feu vers le build SonicOS corrigé et pris en charge pour sa génération. L’avis sur les firmwares de SonicWall indique Gen7 7.3.4-7013 ou ultérieur et Gen8 8.2.3-8015 ou ultérieur. Consultez l’avis PSIRT pour les détails propres à la CVE et pour d’éventuelles recommandations plus récentes avant le déploiement.
Les administrateurs peuvent suivre les étapes suivantes :
- Identifier les passerelles VPN concernées. Inventorier les appliances SonicOS Gen7 et Gen8, physiques et virtuelles, y compris leurs interfaces SSL VPN exposées.
- Vérifier la configuration d’authentification effective. Établir si SAML est activé pour le SSL VPN et si une autre méthode d’authentification peut authentifier des utilisateurs.
- Vérifier le build exact du firmware. Comparer la branche et le build installés avec la version corrigée indiquée par SonicWall pour l’appareil concerné, et pas seulement avec une étiquette de version générale.
- Appliquer la mise à jour prise en charge par le fournisseur. Suivre la procédure de maintenance approuvée de l’organisation, conserver des sauvegardes de la configuration et vérifier l’accès d’administration.
- Tester la politique de connexion prévue. Confirmer que les utilisateurs qui se connectent avec succès passent par SAML et par la MFA lorsque c’est requis, et que les autres chemins de connexion ne peuvent pas accorder un accès équivalent en dehors de la politique.
- Examiner une éventuelle exposition antérieure. Rapprocher les enregistrements de sessions SSL VPN des journaux d’authentification du fournisseur d’identité et enquêter sur les sessions acceptées de manière inattendue.
La dernière étape est un conseil d’investigation défensive, et non une signature d’exploitation publiée par le fournisseur. Les avis publics examinés ne fournissent pas d’ensemble complet d’indicateurs de compromission (indicators of compromise) propres à la CVE. Notre article sur ce qu’il faut faire après avoir corrigé une faille déjà exploitée explique pourquoi un correctif ne dit rien des jours qui l’ont précédé et comment traiter ensuite un équipement de périphérie.
Si l’application du correctif doit être retardée et que l’authentification SAML est utilisée, l’avis de SonicWall, tel que mis à jour le 9 novembre 2026, indique une solution de contournement : désactiver ou supprimer tous les serveurs d’authentification LDAP, RADIUS et TACACS+ actifs configurés sur le pare-feu, chacun sous Device, Users, Settings, Authentication. Il s’agit d’une solution de contournement documentée par le fournisseur, et SonicWall continue d’exhorter ses clients à effectuer la mise à niveau dès que possible. Comme ces serveurs peuvent aussi servir à d’autres connexions, testez d’abord la modification et conservez un chemin d’administration fonctionnel pour éviter tout verrouillage (lockout).
La leçon plus large pour l’accès à distance
Une organisation peut configurer une MFA robuste de manière centralisée et exposer malgré tout son accès à distance si le service protégé accepte une autre méthode d’authentification qui n’applique pas la même politique.
CVE-2026-19868 en est un exemple. Une mise à niveau réussie ne règle pas tout si un chemin de connexion non prévu reste activé, c’est pourquoi les étapes ci-dessus comprennent un test de la manière dont l’accès est réellement accordé.
Avoir configuré SAML et la MFA ne suffit pas. Chaque chemin de connexion VPN autorisé doit appliquer la politique d’accès voulue par l’organisation.
Pour aller plus loin
- SonicWall PSIRT: SNWLID-2026-0014, avis du fournisseur propre à la CVE.
- SonicWall: SonicOS 7.3.4 and 8.2.3 Security Advisory, publié le 3 novembre et mis à jour le 6 novembre 2026.
- CISA Known Exploited Vulnerabilities Catalog, entrée du 6 novembre 2026.
- Canadian Centre for Cyber Security AV26-1133, 6 novembre 2026, y compris l’écart de versions signalé.