CISA a ajouté une vulnérabilité permettant de contourner l’authentification SSLVPN de SonicWall à son catalogue des vulnérabilités exploitées connues (KEV), confirmant que des attaquants ont exploité une faille capable de neutraliser les contrôles d’authentification SAML, y compris l’authentification multifacteur (MFA).
Répertoriée sous le numéro CVE-2026-19868, cette vulnérabilité concerne le logiciel pare-feu SonicOS de SonicWall.
CISA l’a ajoutée au catalogue KEV le 6 novembre, accordant aux agences civiles fédérales jusqu’au 20 novembre pour corriger les systèmes concernés.
La faille est particulièrement préoccupante pour les organisations qui s’appuient sur l’authentification multifacteur basée sur SAML pour protéger les accès à distance. Un attaquant disposant d’identifiants valides pour une autre méthode d’authentification pourrait être en mesure de contourner ces protections supplémentaires.
Comment CVE-2026-19868 contourne l’authentification de SonicWall
Selon l’avis de sécurité de SonicWall, CVE-2026-19868 est une vulnérabilité liée à l’application des règles d’authentification dans le service SSLVPN de SonicOS.
Une exploitation réussie pourrait permettre à une personne disposant d’identifiants valides pour une autre méthode d’authentification de contourner les contrôles d’authentification SAML et l’authentification multifacteur imposée par SAML.
La vulnérabilité ne signifie pas qu’un attaquant non authentifié peut accéder automatiquement à n’importe quel pare-feu concerné. L’attaque nécessite des identifiants valides pour une autre méthode d’authentification, et la configuration de l’authentification SAML est au cœur de l’exposition.
Cette distinction différencie CVE-2026-19868 des vulnérabilités impliquant le détournement de session ou l’accès à distance non authentifié.
La faille diffère également de la vulnérabilité SSLVPN de SonicOSdivulguée en novembre 2025, qui pouvait permettre à des attaquants non authentifiés de faire planter les pare-feu concernés.
SonicWall a corrigé CVE-2026-19868 ainsi que six autres vulnérabilités dans l’avis SNWLID-2026-0014. Cette mise à jour plus large inclut des correctifs pour des faiblesses de l’interface de gestion et des vulnérabilités de déni de service.
Bien que CISA ait confirmé l’exploitation, les informations accessibles au public ne permettent pas d’établir qui a été ciblé, comment les attaquants ont obtenu les identifiants nécessaires ni si la vulnérabilité a été utilisée dans le cadre d’une campagne plus vaste.
Versions de SonicOS concernées et mises à jour requises
SonicWall identifie les versions de firmware suivantes comme concernées :
- Pare-feu Gen 7 : SonicOS 7.3.3-7015 et antérieures.
- Pare-feu Gen 8 : SonicOS 8.2.2-8015 et antérieures.
Les versions corrigées correspondantes sont SonicOS 7.3.4-7013 ou ultérieure pour les plateformes Gen 7 prises en charge, et SonicOS 8.2.3-8015 pour les plateformes Gen 8.
Les administrateurs doivent vérifier le modèle exact de leur équipement avant toute mise à niveau. Les premières notes de version de SonicWall pour la Gen 7 précisent que SonicOS 7.3.4 n’était pas encore disponible pour les pare-feu virtuels NSv, ce qui rend la disponibilité selon la plateforme particulièrement importante.
L’entreprise a publié des instructions de mise à niveau du firmwarecouvrant les générations concernées, les versions prises en charge et le statut des équipements plus anciens.
Les pare-feu Gen 6 et antérieurs ont atteint la fin de leur support et ne reçoivent pas ces mises à jour de firmware. Les organisations qui utilisent encore ces équipements devraient envisager de les remplacer par du matériel pris en charge.
Mesures à prendre dès maintenant par les administrateurs
Les équipes de sécurité doivent donner la priorité aux actions suivantes :
- Identifier les équipements concernés. Recensez les pare-feu SonicWall, notez leurs versions de firmware et déterminez si SSLVPN et l’authentification SAML sont activés.
- Installer le firmware approprié. Appliquez la dernière version de sécurité prise en charge pour chaque plateforme concernée, plutôt que de corriger uniquement CVE-2026-19868.
- Examiner l’activité d’authentification. Recherchez les connexions SSLVPN inhabituelles, les méthodes d’authentification inattendues, les adresses sources inconnues et les modifications de configuration suspectes.
- Évaluer l’exposition des identifiants. Examinez les comptes potentiellement compromis et renouvelez les identifiants lorsque l’enquête révèle un risque.
- Conserver les éléments de preuve forensiques. Conservez les journaux d’authentification et les relevés de configuration pertinents avant d’effectuer des modifications susceptibles d’avoir une incidence sur l’enquête.
L’examen des identifiants est particulièrement pertinent compte tenu de la précédente exposition des sauvegardes de pare-feude SonicWall, qui avait incité l’entreprise à recommander une réinitialisation des identifiants en septembre 2025. Aucun élément de preuve public n’établit de lien entre cet incident et CVE-2026-19868.
CISA fixe au 20 novembre la date limite de correction
La désignation de CVE-2026-19868 dans le catalogue KEV de CISA établit que cette vulnérabilité a été exploitée dans des attaques réelles, et qu’il ne s’agit pas seulement d’une faille théorique.
En vertu de la directive opérationnelle contraignante 26-04, les agences civiles fédérales concernées doivent satisfaire aux exigences applicables en matière de correction et de triage forensique d’ici au 20 novembre.
Les organisations privées ne sont pas soumises à la même échéance fédérale, mais elles sont confrontées à la même vulnérabilité sous-jacente lorsqu’elles utilisent des configurations concernées.
L’application du correctif neutralise le contournement d’authentification documenté. Elle ne permet pas de déterminer si un attaquant a auparavant accédé à l’environnement.
Les organisations doivent donc traiter séparément la mise à jour du firmware et l’évaluation d’une éventuelle compromission, en particulier lorsque des services VPN exposés permettent d’accéder à des systèmes internes sensibles.
À lire également : les précédentes vulnérabilités zero-day de SMA1000de SonicWall concernaient un autre produit d’accès à distance et un autre mécanisme d’attaque ; deux failles exploitées pouvaient être enchaînées pour permettre l’exécution de code à distance.