SiteGuard Server Edition rejoint le catalogue américain des failles exploitées

Une exploitation confirmée, pas seulement un risque théorique

La CISA a ajouté CVE-2026-106931 à son catalogue Known Exploited Vulnerabilities le 20 octobre 2026. Ce registre, souvent abrégé KEV, recense les vulnérabilités pour lesquelles l’agence américaine dispose d’éléments attestant une exploitation réelle. L’entrée concerne SiteGuard Server Edition, un pare-feu applicatif installé directement sur un serveur web pour filtrer les requêtes malveillantes. Son ajout transforme la priorité opérationnelle : les organisations qui utilisent ce produit doivent vérifier sans attendre leur version et leur configuration.

La date du 23 octobre affichée dans le catalogue est l’échéance imposée aux agences civiles fédérales américaines soumises à la directive BOD 26-04. Elle ne crée pas une obligation générale pour les entreprises françaises. Elle reste néanmoins un signal de risque utile, car elle combine une exploitation observée, des privilèges potentiellement très élevés et une fenêtre de correction courte. La CISA indique aussi que l’usage de cette faille dans une campagne de rançongiciel demeure inconnu.

La fonction de statistiques ouvre le chemin vers le système

Le défaut se situe dans la fonction de statistiques de SiteGuard Server Edition. Il s’agit d’une injection de commandes du système d’exploitation, classée CWE-78. Ce type de faille apparaît lorsqu’une valeur contrôlable influence une commande exécutée par le serveur sans neutralisation suffisante. Le bulletin public ne fournit ni charge utile ni procédure d’exploitation. Il établit en revanche qu’un attaquant peut parvenir à faire exécuter des commandes arbitraires sur la machine qui héberge le produit.

Les commandes peuvent s’exécuter avec les droits root sous les systèmes de type Unix ou SYSTEM sous Windows. Ces comptes disposent des autorisations les plus étendues sur leur plateforme. Une exploitation réussie peut donc donner accès à des fonctions bien au-delà du composant de statistiques. Les sources publiques ne disent toutefois pas ce que les attaquants observés ont réellement exécuté, ni s’ils ont consulté des données, installé un outil persistant ou perturbé un service.

L’évaluation CVSS publiée par JVN attribue un score de 8,5 avec la version 4.0 et de 7,8 avec la version 3.0. Les vecteurs décrivent un accès local et la possession préalable de faibles privilèges. Cette indication ne suffit pas à reconstituer le chemin d’attaque. Aucun détail public ne permet notamment d’affirmer comment les premiers droits sont obtenus ou si une chaîne avec une autre faille a été utilisée lors des incidents constatés.

Les versions concernées dépendent de la plateforme

Le risque existe lorsque la fonction de statistiques est active, ce qui correspond au réglage par défaut selon EG Secure Solutions et JVN. Pour Apache, Nginx et IIS hors FreeBSD, les éditions à partir de la version 2.20 et antérieures à la version 8.00 Update 5 sont concernées. Une exception est documentée pour IIS : les versions 3.10 à 4.00 Update 4 ne sont pas affectées.

Sur FreeBSD, les éditions Apache et Nginx à partir de la version 2.20 et antérieures à la version 7.00 Update 6 sont affectées. Une simple recherche du nom du produit dans l’inventaire ne suffit donc pas. L’équipe technique doit relever la plateforme, l’édition, la version exacte et l’état de la fonction de statistiques. JPCERT/CC indique que le produit est largement utilisé au Japon, mais aucune estimation publique du nombre d’installations exposées n’accompagne l’alerte.

Préserver les traces avant de corriger

La chronologie publique commence avant l’ajout au catalogue américain. Le fournisseur dit avoir prévenu ses clients sous contrat direct le 29 septembre 2026. L’avis public d’EG Secure Solutions et la note JVN ont été publiés le 14 octobre. La CISA a ensuite inscrit la faille dans KEV le 20 octobre. Cette séquence montre que la correction était disponible avant la confirmation américaine, sans révéler la date des premières attaques ni leur nombre.

Le fournisseur avertit qu’une mise à jour ou l’application du correctif peut effacer certaines traces d’attaque. Il demande donc de télécharger et de conserver les informations de diagnostic depuis l’interface d’administration avant toute modification. Cette précaution ne remplace pas une sauvegarde adaptée ni une investigation complète, mais elle évite de détruire immédiatement une partie des éléments utiles pour déterminer si le serveur a été compromis.

La solution privilégiée consiste à installer la version 8.00 Update 5 pour Apache, Nginx et IIS hors FreeBSD, ou la version 7.00 Update 6 pour Apache et Nginx sous FreeBSD. Le fournisseur propose aussi un correctif qui remplace les fichiers utilisés par le traitement statistique, y compris pour des versions arrivées en fin de support. Lorsque la mise à jour ou ce correctif ne peuvent pas être appliqués immédiatement, JPCERT/CC présente la désactivation de la fonction de statistiques comme mesure de contournement.

Ce que les responsables doivent vérifier maintenant

La première étape consiste à identifier chaque serveur équipé de SiteGuard Server Edition et à confirmer les quatre paramètres qui déterminent l’exposition : plateforme, édition, version et activation des statistiques. Avant de modifier un système potentiellement touché, il faut préserver les diagnostics indiqués par le fournisseur et noter l’heure des opérations. L’équipe peut ensuite installer la version corrigée, appliquer le correctif fourni ou désactiver temporairement les statistiques selon les contraintes de son environnement.

Une vérification de compromission reste nécessaire puisque l’exploitation est confirmée. Elle doit s’appuyer sur les traces conservées, les journaux disponibles et les consignes actualisées du fournisseur ou de JPCERT/CC. Les sources publiques consultées ne fournissent aucun indicateur de compromission, ne nomment aucun groupe, aucune victime et aucun pays ciblé. Il faut donc éviter d’attribuer une activité à cette faille sur la seule base d’un comportement inhabituel.

Les limites sont importantes : l’étendue des attaques, leur objectif et le chemin d’accès initial ne sont pas publics. L’inscription dans KEV confirme l’exploitation de CVE-2026-106931, mais pas un scénario universel pour tous les serveurs. La réponse proportionnée consiste à corriger rapidement, à préserver les preuves avant l’intervention et à documenter ce qui a été contrôlé. Toute conclusion sur une intrusion doit ensuite reposer sur les éléments propres au système examiné.