Sept vulnérabilités affectant les pare-feu SonicWall viennent d'être corrigées. L'une d'elles permet de contourner la double authentification des VPN d'entreprise et figure est déjà exploitée.
SonicWall vient de corriger une faille dans le service VPN de ses pare-feu qui permet de contourner la double authentification exigée par les entreprises. En utilisant des identifiants valides pour une autre méthode de connexion, un attaquant peut éviter les contrôles SAML et la vérification supplémentaire qui leur est associée. Référencée CVE-2026-19868 et notée 7,1/10, la vulnérabilité figure déjà au catalogue KEV de la CISA, qui recense les failles exploitées dans des attaques réelles.
Protégez votre entreprise gratuitement pendant 30 jours
Découvrez Bitdefender Ultimate Small Business Security et protégez votre activité contre les cybermenaces. Aucune coordonnée bancaire requise.
Une autre méthode de connexion pour contourner la double authentification
Dans le détail, le problème concerne le service SSL-VPN de SonicOS, qui permet d'accéder à distance au réseau d'une entreprise. Pour vérifier l'identité des utilisateurs et utilisatrices, le VPN peut s'appuyer sur SAML, un standard qui permet de confier cette tâche à un fournisseur d'identité. Celui-ci peut alors exiger une deuxième vérification, par exemple à l'aide d'un code temporaire ou d'une validation sur smartphone.
Mais SonicOS accepte aussi d'autres méthodes de connexion au VPN. Or, il se trouve que dans les versions vulnérables du système d’exploitation, un attaquant qui dispose d'identifiants valides pour l'une d'elles peut se connecter sans passer par les contrôles SAML, ni par la double authentification exigée par le fournisseur d'identité.
Cette faille ne concerne que les SSL-VPN pour lesquels SAML est activé. Ni SonicWall ni la CISA n'ont précisé comment elle a été exploitée ou combien d'organisations ont été touchées.
Six autres failles corrigées dans la foulée
Le bulletin de sécurité de SonicWall recense six autres vulnérabilités de SonicOS, dont deux notées 8,8/10. Elles concernent une politique de sécurité trop permissive entre domaines et des contrôles insuffisants sur les sessions. Trois autres sont des débordements de mémoire dans les services SSL-VPN et TACACS+, susceptibles de provoquer des dénis de service. La dernière touche au hachage des mots de passe sur les appliances virtuelles.
Les patchs concernent les pare-feu de générations 7 et 8, physiques comme virtuels. Les équipements Gen7 utilisant SonicOS 7.3.3-7015 ou une version antérieure doivent passer au minimum à la version 7.3.4-7013. Pour les Gen8, les versions 8.2.2-8015 et antérieures doivent être remplacées par SonicOS 8.2.3-8015 ou une version plus récente.
SAML (Security Assertion Markup Language) est un standard d’authentification fédérée : le VPN délègue la connexion à un fournisseur d’identité (IdP) plutôt que de gérer lui-même les preuves d’identité. L’utilisateur s’authentifie auprès de l’IdP, qui peut appliquer des règles comme la MFA/2FA (code TOTP, push mobile, clé matérielle, etc.). Une fois la vérification réussie, l’IdP envoie au VPN une « assertion » signée attestant que l’utilisateur est bien authentifié. Le VPN se base sur cette assertion pour ouvrir la session, sans manipuler directement le second facteur. Le point clé est que la MFA n’est réellement obligatoire que si le VPN force le passage par le flux SAML pour toute connexion.
Un SSL-VPN peut accepter plusieurs mécanismes d’authentification (par exemple comptes locaux, LDAP/RADIUS, certificats, ou SAML via un IdP). Le contournement décrit correspond à une situation où, même si SAML est activé pour imposer une MFA, une autre voie d’authentification reste utilisable et ne déclenche pas les contrôles SAML. Avec des identifiants valides sur cette voie alternative, un attaquant peut obtenir une session VPN sans passer par le second facteur exigé côté IdP. Ce n’est pas une “cassure” cryptographique de la 2FA : c’est un problème de logique d’authentification et de cohérence des politiques entre méthodes. La mitigation typique consiste à restreindre/neutraliser les méthodes non-SAML ou à segmenter strictement quels utilisateurs et portails peuvent s’y connecter.
Le KEV (Known Exploited Vulnerabilities) est une liste tenue par la CISA qui recense des vulnérabilités pour lesquelles il existe des preuves d’exploitation active dans le monde réel. Y figurer implique que la faille n’est pas seulement théorique : des attaquants l’utilisent déjà, ce qui augmente fortement le risque pour les environnements exposés. Pour les organisations, c’est un outil de priorisation : une CVE présente dans KEV passe généralement avant des failles au score CVSS plus élevé mais non exploitées. Dans de nombreux cadres de conformité ou de gestion des risques, KEV déclenche des délais de remédiation plus courts. Concrètement, cela pousse à patcher vite, à réduire l’exposition (désactiver SSL-VPN si possible) et à vérifier les journaux d’accès pour détecter d’éventuelles intrusions.
