Un acteur malveillant jusque-là inconnu a passé des semaines à s’infiltrer discrètement dans des boîtiers VPN d’entreprise SonicWall en utilisant des failles que personne, en dehors de l’attaque elle-même, ne connaissait. SonicWall a révélé et corrigé les failles le 14 juillet 2026, mais la société de réponse à incident Volexity a retracé une exploitation active remontant au moins au 22 juin, soit près d’un mois d’exposition avant que l’éditeur ne rattrape le retard.
Si vous administrez une infrastructure VPN d’entreprise, c’est une situation à corriger immédiatement. Si vous êtes un particulier sans matériel SonicWall en vue, ça reste utile à comprendre, parce que le schéma derrière cette histoire se répète constamment du côté entreprise de l’industrie VPN.
Ce que sont réellement ces failles
Les failles touchent les boîtiers Secure Mobile Access (SMA) 1000 de SonicWall, spécifiquement les modèles 6210, 7210 et 8200v. Elles sont référencées CVE-2026-15409, une faille critique de type server-side request forgery, et CVE-2026-15410, une faille d’injection de commande de sévérité élevée, selon la couverture de BleepingComputer. Enchaînées, les deux failles permettent à un attaquant d’atteindre en profondeur le boîtier sans identifiants valides, jusqu’à obtenir un accès root complet.
SonicWall a diffusé les correctifs 12.4.3-03453 et 12.5.0-02835 pour traiter les failles lors de leur révélation le 14 juillet. Quiconque fait tourner du matériel SMA 1000 sans avoir appliqué ces correctifs fait actuellement tourner une infrastructure exposée.
Qui est derrière tout ça, et ce qu’ils ont fait une fois à l’intérieur
L’attaquant, suivi sous la désignation UTA0533, est nouveau dans le suivi public des renseignements sur les menaces, ce qui signifie que cette campagne constitue en fait son introduction. Selon l’analyse technique de Volexity, le groupe a enchaîné les failles SSRF et d’injection de commande pour compromettre les boîtiers SMA 1000, installer un malware sur mesure conçu spécifiquement pour cette campagne, capturer le trafic réseau passant par l’appareil compromis, et tenter un mouvement latéral vers les réseaux situés derrière la passerelle VPN.
Cette combinaison, un malware conçu pour la cible précise plutôt qu’un outil générique du marché noir, plus la capture de trafic et les tentatives de mouvement latéral, pointe vers un acteur capable et patient plutôt qu’une opération opportuniste de scan à grande échelle. The Hacker News a noté que la chaîne d’exploitation était conçue spécifiquement pour obtenir un accès root sur le boîtier, le niveau de contrôle le plus élevé disponible, plutôt que de se contenter d’un point d’ancrage moindre.
L’écart d’un mois, voilà la vraie histoire
Les détails techniques comptent pour les défenseurs, mais c’est la chronologie qui devrait inquiéter tout le monde. UTA0533 disposait d’exploits zero-day enchaînés et fonctionnels, et les utilisait activement contre de vraies cibles pendant près d’un mois avant que SonicWall ne sache même que ces failles existaient. Le rapport de Cybersecurity Dive sur la chronologie de Volexity situe la première exploitation confirmée au 22 juin, soit trois semaines pleines avant la révélation et le correctif du 14 juillet.
C’est cet écart qui cause les dégâts. Chaque organisation faisant tourner du matériel SMA 1000 non corrigé pendant cette fenêtre était exposée à un attaquant qui savait déjà comment entrer, sans avis public, sans CVE, et sans correctif à appliquer même en surveillant attentivement. C’est la forme classique d’une faille zero-day : la vulnérabilité existe et est exploitée avant même que les responsables de la corriger ne sachent qu’il faut regarder.
Envie de comparer tous les VPN côte à côte ? Consultez notre tableau comparatif complet avec les scores sur 18 critères.
Ce à quoi ressemblent les indicateurs de compromission de Volexity
Pour les défenseurs qui essaient de déterminer si leurs propres boîtiers ont été touchés pendant la fenêtre d’exposition, le rapport de Volexity détaille des éléments précis : des requêtes sortantes inhabituelles cohérentes avec la chaîne SSRF, une exécution de processus inattendue liée à l’étape d’injection de commande, et un comportement de capture de trafic sur les appareils compromis qui n’apparaîtrait pas dans un déploiement SMA 1000 normal. Aucun de ces éléments ne nécessite d’outils exotiques à vérifier, une simple revue des journaux à partir du 22 juin couvre l’essentiel, mais encore faut-il que quelqu’un aille vraiment regarder, ce qui est l’étape qu’on saute sous la charge opérationnelle normale jusqu’à ce qu’une histoire comme celle-ci en fasse une urgence.
Pourquoi les passerelles VPN d’entreprise restent le point d’entrée favori
C’est au moins la troisième grande histoire de faille zero-day sur un boîtier VPN d’entreprise ces derniers mois, après la faille IKEv1 de Check Point exploitée par un affilié de Qilin et la faille SSL-VPN de SonicWall liée à la brèche du groupe Akira chez des dizaines de banques plus tôt cette année. Ce n’est pas une coïncidence. Ces boîtiers font face à internet public par conception, ils se trouvent hors des protections qui couvrent les postes de travail habituels, et une seule exploitation réussie donne à un attaquant un point d’ancrage à l’intérieur du périmètre réseau plutôt qu’une simple machine compromise.
Les chercheurs en sécurité signalent ce schéma depuis des années sans que grand-chose ne change du côté des éditeurs ou des clients. La solution, corriger les équipements en bordure de réseau selon un calendrier d’urgence plutôt qu’un cycle de maintenance normal, reste simple à énoncer et systématiquement difficile à exécuter à grande échelle dans des organisations qui doivent suivre des centaines de boîtiers.
Que faire concrètement
Si vous administrez des boîtiers SonicWall SMA 1000, appliquez immédiatement les correctifs 12.4.3-03453 ou 12.5.0-02835 si ce n’est pas déjà fait, et passez en revue les journaux depuis au moins le 22 juin à la recherche de signes de la chaîne d’exploitation documentée par Volexity. L’avis de SonicWall et le rapport technique de Volexity listent tous deux des indicateurs de compromission à vérifier.
Si vous êtes un employé à distance dont l’entreprise utilise du matériel SonicWall, il n’y a rien à corriger de votre côté, mais ne soyez pas surpris par une reconnexion forcée du client VPN ou une exigence de changement de mot de passe dans les jours qui viennent, c’est la réponse attendue de la part de votre service informatique.
Si vous êtes un utilisateur VPN personnel sans passerelle d’entreprise dans le tableau, ça ne touche en rien votre configuration. Ça reste un point de repère utile pour évaluer tout produit lié à un VPN que votre employeur vous demande d’installer : un logiciel d’accès distant d’entreprise porte un profil de risque fondamentalement différent de l’appli VPN grand public sur votre téléphone, et c’est exactement pour ça que cette distinction existe. Un fournisseur comme NordVPN n’a aucune surface d’attaque entrante équivalente, puisqu’il ne fait jamais que des connexions sortantes en votre nom.
Un acteur capable et jusque-là inconnu a fait tourner des exploits zero-day enchaînés contre des passerelles VPN d'entreprise pendant près d'un mois avant même que l'éditeur ne sache qu'il fallait regarder. La réponse de SonicWall, une fois alerté, a été raisonnablement rapide : des correctifs diffusés le jour même de la révélation. Mais c'est la fenêtre d'exposition qui compte, et c'est la même histoire que produisent les boîtiers VPN d'entreprise année après année. Si votre organisation fait tourner ce matériel, corriger aujourd'hui n'est pas optionnel.
Sources : BleepingComputer sur les failles zero-day exploitées | Rapport technique de Volexity | The Hacker News sur la chaîne d’exploitation | Cybersecurity Dive sur la chronologie du 22 juin