CVE-2026-15409 et CVE-2026-15410 : UTA0533 a rooté des SonicWall SMA1000 un mois avant la divulgation

Rapport CTI technique du 2 août 2026

Résumé exécutif

Volexity a publié le 17 juillet 2026 une analyse technique complète d'une campagne de zero-day contre les passerelles SonicWall SMA1000 (Secure Mobile Access), menée par un acteur jusqu'alors inconnu que l'entreprise suit sous le nom UTA0533. Les premiers signes de compromission remontent au 22 juin 2026, soit près d'un mois avant que SonicWall ne publie ses correctifs et alerte publiquement le 14 juillet. L'acteur a enchaîné deux vulnérabilités, CVE-2026-15409 (SSRF critique sur le endpoint /wsproxy) et CVE-2026-15410 (injection de commande dans la console de gestion de l'appliance), pour obtenir une exécution de commandes en tant que root sur les modèles 6210, 7210 et 8200v.

Une fois root, UTA0533 a déployé un dropper personnalisé baptisé KNUCKLEBALL par Volexity, qui installe à son tour deux implants Java conçus spécifiquement pour l'architecture SMA1000 : Sou5, un proxy inverse pour le tunneling de trafic, et ORANGETAIL, un webshell capable d'exécuter dynamiquement des payloads Java chiffrés dans une session HTTP. Volexity qualifie la sophistication technique de la campagne de significative, tout en notant que l'acteur a eu moins de succès pour rebondir vers les réseaux internes des victimes une fois l'appliance compromise. Les correctifs sont disponibles depuis les versions 12.4.3-03453 et 12.5.0-02835 ; toute organisation exploitant du SMA1000 doit considérer ses appliances comme potentiellement compromises depuis fin juin si elles n'ont pas encore été patchées et inspectées.

Chronologie

Fiche vulnérabilité (format fiche CTI)

CVE-2026-15409 | Critique | SonicWall SMA1000, endpoint /wsproxy (modèles 6210, 7210, 8200v)

SSRF (CWE-918) permettant à un attaquant non authentifié d'établir des tunnels WebSocket vers des services normalement accessibles uniquement en local sur l'appliance. L'abus du endpoint fonctionne lorsque la requête utilise un user-agent "SMA Connect Agent" associé à une valeur bmID commençant par -3389, un détail de mise en œuvre qui contourne les contrôles d'accès prévus pour ce endpoint. Conditions d'exploitation : accès réseau à l'interface SMA1000, aucune authentification requise. L'exploitation expose des services internes normalement cloisonnés, dont CouchDB et le service de gestion de l'appliance. PoC disponible : non publié publiquement à la date de rédaction, mais la mécanique précise de contournement (user-agent et préfixe bmID) est documentée dans le rapport Volexity. Patch/mitigation : mise à jour vers 12.4.3-03453 ou 12.5.0-02835.

CVE-2026-15410 | Élevée | SonicWall SMA1000, RPC sysCtrl.execRemoveHotfix de l'Appliance Management Console

Injection de commande (CWE-78) dans la méthode RPC sysCtrl.execRemoveHotfix de la console de gestion. Une fois la valeur product_uuid de l'appliance obtenue via l'accès CouchDB exposé par CVE-2026-15409, l'attaquant peut invoquer cette méthode pour exécuter des commandes arbitraires avec les privilèges root du système. Conditions d'exploitation : accès préalable au product_uuid de l'appliance, généralement obtenu via la première étape de la chaîne. Le mécanisme exact d'interrogation de CouchDB reste non documenté par Volexity. PoC disponible : non publié, mécanique documentée dans le rapport technique Volexity. Patch/mitigation : mêmes versions correctives que CVE-2026-15409, les deux vulnérabilités étant corrigées dans le même correctif.

Diagramme de la chaîne d'attaque

Chaîne reconstruite à partir du rapport technique Volexity "Proxying to Compromise" et de la couverture BleepingComputer.

Analyse technique

Étape 1 : abus du proxy WebSocket /wsproxy pour atteindre les services internes (CVE-2026-15409)

UTA0533 envoie une requête vers le endpoint /wsproxy en usurpant un user-agent "SMA Connect Agent" et en fournissant une valeur bmID débutant par -3389. Cette combinaison contourne la restriction censée limiter ce proxy aux communications légitimes entre l'agent client et l'appliance, et ouvre un tunnel WebSocket non authentifié vers des services qui ne devraient être accessibles que localement sur le boîtier, notamment l'instance CouchDB embarquée et le service de gestion.

Étape 2 : extraction du product_uuid via CouchDB

Une fois le tunnel établi, l'attaquant interroge la base CouchDB exposée pour en extraire le product_uuid de l'appliance. Cette valeur constitue un prérequis pour la seconde étape de la chaîne : Volexity n'a pas pu déterminer avec certitude la méthode exacte utilisée pour interroger CouchDB, ce qui suggère soit une requête directe sur l'API REST de CouchDB, soit un abus d'une route applicative non documentée.

Étape 3 : injection de commande via sysCtrl.execRemoveHotfix (CVE-2026-15410)

Muni du product_uuid, l'attaquant invoque la méthode RPC sysCtrl.execRemoveHotfix de l'Appliance Management Console. Cette méthode, censée gérer la suppression de correctifs, ne valide pas correctement ses paramètres et permet l'injection de commandes shell exécutées avec les privilèges root du système d'exploitation sous-jacent de l'appliance.

Étape 4 : déploiement du dropper KNUCKLEBALL et des implants Java

Avec un accès root stable, UTA0533 dépose un script Python nommé deploy_new.py, identifié par Volexity comme le dropper KNUCKLEBALL. Ce dropper installe deux archives Java : agent_wp8.jar (Sou5), qui fait office de proxy inverse pour tunneler du trafic à travers l'appliance compromise et maintenir un accès discret aux ressources internes, et agent_wp9.jar (ORANGETAIL), un webshell Java capable de recevoir et d'exécuter dynamiquement des payloads chiffrés au sein d'une session HTTP.

Étape 5 : persistance et exposition du webshell via modification de nginx

Pour assurer un accès distant durable à ORANGETAIL, les attaquants modifient la configuration nginx de l'appliance afin d'exposer le webshell au-delà du périmètre local. Ils installent également ROOTRUN, un outil d'escalade de privilèges dédié qui garantit l'exécution de commandes en tant que root même si le contexte d'exécution initial change. Volexity note que, malgré cette sophistication, l'acteur n'a obtenu qu'un succès limité pour pivoter ensuite vers les réseaux internes des organisations victimes.

Indicateurs de compromission

Volexity et SonicWall ont publié des listes d'IOC et des règles YARA complémentaires dans leurs rapports respectifs, non reproduites intégralement ici : se référer au rapport Volexity original pour les hachages de fichiers et signatures complètes.

MITRE ATT&CK

Aucune cartographie officielle n'a été publiée par Volexity ou SonicWall à la date de rédaction. La correspondance suivante est une lecture technique construite à partir de la chaîne documentée, pas une attribution vendeur.

Remédiation : checklist opérationnelle

1. Mettre à jour toutes les appliances SonicWall SMA1000 (modèles 6210, 7210, 8200v) vers la version 12.4.3-03453 ou 12.5.0-02835 sans délai.
2. Considérer comme potentiellement compromise toute appliance exposée sur Internet et non patchée depuis le 22 juin 2026, date du premier signe de compromission identifié par Volexity.
3. Rechercher la présence des fichiers deploy_new.py, agent_wp8.jar et agent_wp9.jar sur le système de fichiers de l'appliance, ainsi que toute modification suspecte de la configuration nginx.
4. Analyser les journaux d'accès pour des requêtes vers /wsproxy présentant un user-agent "SMA Connect Agent" combiné à une valeur bmID débutant par -3389.
5. Auditer les journaux CouchDB embarqués pour des requêtes anormales ayant permis l'extraction du product_uuid de l'appliance.
6. En cas de compromission confirmée ou suspectée, considérer l'appliance comme totalement compromise (accès root obtenu) et procéder à une réinstallation complète plutôt qu'à un simple nettoyage, puis effectuer une rotation de tous les identifiants et secrets exposés via l'appliance.
7. Appliquer les règles YARA et indicateurs publiés par Volexity et SonicWall dans leurs rapports techniques pour la détection rétrospective.
8. Segmenter le réseau interne accessible depuis les appliances SMA1000 : Volexity note que l'acteur a eu un succès limité pour pivoter en interne, ce qui suggère qu'une segmentation réseau correcte reste un frein efficace même après compromission de la passerelle.

Sources

• SonicWall SMA1000 flaws exploited as zero-days to push custom malware
• Proxying to Compromise: SonicWall Secure Mobile Access 0-day Exploitation - Volexity
• SonicWall SMA Zero-Days Exploited Before Disclosure to Gain Root Access
• Volexity Uncovers Zero-Day Campaign Targeting SonicWall VPN Appliances
• Hackers Exploit SonicWall SMA Zero-Days to Gain Root Access and Deploy ORANGETAIL Webshell