Des attaquants exploitent une injection de commandes root dans le WAF SiteGuard
Le 18 octobre 2026, JPCERT/CC et l’éditeur e-guardian confirment que CVE-2026-106931, une injection de commandes OS dans la fonction de statistiques du WAF SiteGuard Server Edition, est exploitée dans la nature. Avant de patcher, téléchargez les informations de diagnostic : la remédiation peut effacer les traces de l’attaque.
18 octobre 2026. JPCERT/CC et l’éditeur japonais e-guardian confirment que la faille CVE-2026-106931 est exploitée dans la nature contre SiteGuard Server Edition. 18 octobre 2026. L’injection de commandes touche la fonction de statistiques du WAF, activée par défaut. 29 septembre 2026. L’éditeur avait déjà prévenu ses clients disposant d’un contact de support direct. Pourquoi c’est grave : le produit censé filtrer les attaques web devient lui-même la porte d’entrée, avec une exécution de commandes en root ou SYSTEM sur la machine qui héberge le pare-feu.
Le paradoxe du pare-feu qui ouvre la porte
SiteGuard est l’un des WAF dominants du marché japonais. L’éditeur revendique la protection de plus de 1,5 million de sites, et le plug-in WordPress du produit est actif sur environ 500 000 sites, d’après les compteurs de WordPress.org. Ce type de produit est installé au plus près de la cible — souvent sur le serveur qui héberge l’application — précisément pour intercepter et bloquer le trafic malveillant avant qu’il n’atteigne le code applicatif.
C’est cette position qui rend la faille aussi lourde de conséquences. Une injection de commandes OS dans un WAF ne contourne pas le périmètre : elle le traverse de l’intérieur. L’attaquant qui l’exploite n’obtient pas un simple accès à une application, il exécute des commandes avec les privilèges du processus du WAF, c’est-à-dire root sur Linux ou SYSTEM sur Windows, selon la plateforme. Le gardien devient le point d’ancrage.
Une fonction de statistiques activée par défaut
Le vecteur est d’autant plus gênant qu’il n’est pas marginal. La faille vit dans la fonction de statistiques de SiteGuard Server Edition, une brique qui agrège des métriques sur le trafic bloqué et autorisé. Or cette fonction est activée par défaut : la plupart des installations l’exécutent sans même le savoir, ce qui élargit la surface vulnérable à la quasi-totalité des déploiements concernés. Une fonction de reporting, pensée pour l’observabilité, devient un chemin d’exécution de commandes à distance.
Les versions touchées couvrent l’essentiel du parc :
- SiteGuard Server Edition pour Apache httpd, Nginx et IIS (hors FreeBSD) : versions 2.20 et ultérieures, avant la 8.00 Update 5.
- SiteGuard Server Edition pour Apache httpd et Nginx sous FreeBSD : versions 2.20 et ultérieures, avant la 7.00 Update 6.
JPCERT/CC précise une exception : les éditions IIS 3.10 à 4.00 Update 4 incluses ne sont pas concernées. Mais pour le reste, la fenêtre est large — des versions 2.20 jusqu’aux mises à jour de 2026, soit plusieurs années d’installations potentiellement vulnérables.
Un correctif qui peut effacer les preuves
L’éditeur propose des versions corrigées et, pour les installations qui ne peuvent pas monter de version, un patch qui remplace les fichiers du traitement des statistiques, y compris sur des versions en fin de vie. C’est un détail rare qui mérite d’être relevé : e-guardian maintient un correctif pour des produits qui ne sont plus supportés, signe que la faille est jugée suffisamment critique pour déroger à la politique habituelle.
Mais l’alerte de l’éditeur contient une mise en garde inhabituelle : la remédiation peut effacer les traces de l’attaque. Avant d’appliquer le correctif, les administrateurs doivent télécharger les informations de diagnostic depuis l’interface de gestion web, via le chemin Écran de gestion web → Informations de diagnostic → Télécharger les informations de diagnostic. En d’autres termes, si une instance a déjà été compromise, la précipitation à patcher détruit précisément ce qui permettrait d’établir la chronologie de l’intrusion.
Le risque structurel des WAF hébergés sur la machine qu’ils protègent
Cet incident dépasse SiteGuard. Il rappelle une distinction que les équipes sécurité connaissent mais sous-estiment : un WAF peut être hébergé — installé sur la machine qui sert l’application, comme SiteGuard Server Edition ou ModSecurity — ou délégué — servi depuis le bord du réseau, comme Cloudflare, AWS WAF ou Imperva.
Le modèle hébergé a un avantage réel : il voit le trafic décrypté, au plus près du code, et il ne dépend d’aucun tiers pour la terminaison TLS. Mais il concentre le risque. Quand une faille comme CVE-2026-106931 frappe un WAF hébergé, l’attaquant ne gagne pas seulement un filtrage à contourner : il gagne root sur l’origine elle-même. Le pare-feu, la base de données et l’application partagent la même machine — une seule faille suffit à les compromettre tous.
Le modèle délégué inverse le compromis. Chez un fournisseur de bord, une faille du WAF reste une faille du fournisseur — grave, mais elle ne donne pas root sur votre serveur d’application. En contrepartie, vous confiez à un tiers la terminaison TLS et une copie de votre trafic, et vous acceptez une dépendance sur sa latence et sa disponibilité.
Il n’y a pas de bonne réponse universelle, mais il y a une règle : ne traitez jamais un WAF hébergé comme un simple module. Il fait partie du noyau de confiance de la machine, et il mérite la même cadence de patch, la même surveillance et la même segmentation que l’application qu’il protège. Un WAF qu’on installe puis qu’on oublie n’est pas une défense — c’est une porte d’entrée différée.
Ce qu’il faut faire, concrètement
La séquence tient en trois étapes :
- Préserver les preuves : téléchargez les informations de diagnostic avant toute mise à jour, et conservez-les hors de la machine touchée.
- Corriger ou patcher : montez vers la 8.00 Update 5 (ou la 7.00 Update 6 sous FreeBSD), ou appliquez le patch de remplacement fourni pour les versions en fin de vie.
- Traiter la machine comme potentiellement compromise : l’exploitation est confirmée dans la nature. Une exécution root ne se limite pas au WAF — elle peut avoir servi de point d’appui pour persister ailleurs sur le système.
Une fois le correctif appliqué, vérifiez l’état de la machine. Une injection de commandes ne laisse pas forcément un fichier modifié, mais elle laisse souvent un processus, une connexion sortante ou un binaire ajouté : examinez les processus inhabituels, les connexions réseau sortantes du processus du WAF, et l’intégrité des fichiers du répertoire d’installation. Le délai entre l’alerte réservée aux clients directs — le 29 septembre — et la publication publique du 18 octobre laisse aussi supposer que les attaquants ont disposé de près de trois semaines pour opérer avant que la masse des administrateurs ne soit informée.
Le réflexe à abandonner est celui qui consiste à traiter un WAF comme une boîte noire qu’on installe puis qu’on oublie. SiteGuard a bien publié son correctif et son alerte, mais l’identité des attaquants, les victimes et l’ampleur exacte de la campagne restent inconnues — ni l’avis du CERT japonais ni le bulletin de l’éditeur ne les détaillent. L’absence de chiffres ne doit pas être lue comme une absence d’enjeu : c’est au contraire le moment où chaque exploitant doit vérifier sa propre surface.
Verdict
Si vous exploitez SiteGuard Server Edition, le risque est binaire : la faille est critique, elle est déjà exploitée, et elle donne root ou SYSTEM. Ne la traitez pas comme un patch de routine — téléchargez d’abord les preuves, puis corrigez dans la foulée. Si vous n’utilisez pas SiteGuard, la leçon dépasse ce produit : un pare-feu applicatif hébergé sur la machine qu’il protège concentre le risque, et sa fonction la plus banale — ici, des statistiques — peut devenir le chemin d’entrée. Le périmètre qui vous protège est aussi une surface d’attaque, et il faut le patcher comme n’importe quel autre service exposé.