Des attaquants exploitent la CVE-2026-106931, une faille d’injection de commandes système dans SiteGuard Server Edition qui permet d’exécuter des commandes avec les privilèges root sur les systèmes Linux et FreeBSD, ou avec les privilèges SYSTEM sous Windows.
L’application du correctif ne constitue qu’une partie de la réponse. EG Secure Solutions avertit qu’une mise à jour ou l’application de son correctif peut effacer les traces de l’attaque ; les organisations concernées doivent donc enregistrer les informations de diagnostic de SiteGuard avant toute modification de remédiation.
La vulnérabilité se trouve dans la fonction de statistiques de SiteGuard Server Edition, activée par défaut. Selon Japan Vulnerability Notes, une exploitation réussie permet d’exécuter des commandes système arbitraires avec les privilèges de l’hôte concerné.
Qui est concerné par la CVE-2026-106931 ?
SiteGuard Server Edition est un pare-feu applicatif web (WAF) qui s’intègre à un serveur web au lieu de fonctionner uniquement comme une appliance réseau distincte.
La CVE-2026-106931 affecte SiteGuard Server Edition à partir de la version 2.20 lorsque la fonction de statistiques est activée. Les plages vulnérables exactes dépendent de la plate-forme :
- Apache httpd, Nginx et IIS : Versions 2.20 et ultérieures antérieures à 8.00 Update 5.
- Apache httpd et Nginx sous FreeBSD : Versions 2.20 et ultérieures antérieures à 7.00 Update 6.
- Versions d’IIS 3.10 à 4.00 Update 4 : Non concernées.
La fonction de statistiques étant activée par défaut, les administrateurs ne doivent pas considérer une installation comme sûre au seul motif que personne n’a activé volontairement cette fonction.
La faille est classée CWE-78, injection de commandes système. Son score de base CVSS 4,0 est de 8,5, soit un niveau élevé, tandis que son score CVSS 3,0 est de 7,8. Le score CVSS à lui seul ne constitue pas le facteur décisif ici, car l’éditeur a déjà confirmé une exploitation dans la nature.
Un point doit être traité avec attention : les avis publics ne décrivent pas d’exploitation distante non authentifiée.
Le vecteur CVSS officiel indique que le vecteur d’attaque est local, qu’il exige des privilèges faibles et qu’il ne requiert aucune interaction utilisateur. Ni EG Secure Solutions ni le JPCERT/CC n’ont révélé comment les attaquants obtiennent cet accès initial, quelles charges utiles ils utilisent ni quelles organisations ont été compromises.
La chaîne d’exploitation reste donc inconnue. Les équipes de sécurité ne doivent pas supposer que la vulnérabilité peut être déclenchée directement depuis l’internet public, mais elles ne doivent pas non plus attendre davantage de détails techniques avant de traiter les systèmes correspondant aux configurations concernées.
Enregistrer les éléments de preuve de diagnostic avant d’appliquer le correctif
L’élément inhabituel de cette réponse tient à l’ordre des opérations.
Dans son bulletin de sécurité, EG Secure Solutions indique qu’une mise à jour ou l’application d’un correctif à SiteGuard peut supprimer les éléments attestant d’une attaque. Avant toute remédiation, les administrateurs doivent utiliser l’interface de gestion web pour télécharger et conserver les informations de diagnostic :
Écran de gestion web > Informations de diagnostic > Télécharger les informations de diagnostic
Conservez cette archive dans un emplacement distinct du serveur concerné. Si une compromission est suspectée, elle doit être intégrée aux éléments habituels de criminalistique numérique et de réponse à incident de l’organisation, plutôt que de rester uniquement sur le système faisant l’objet de l’enquête.
Après avoir préservé les éléments de diagnostic, les organisations disposent de trois options prises en charge :
- Mettre à jour les installations Apache, Nginx ou IIS vers la version 8.00 Update 5 ou ultérieure.
- Mettre à jour les installations Apache ou Nginx sous FreeBSD vers la version 7.00 Update 6 ou ultérieure.
- Appliquer le correctif autonome de l’éditeur si une mise à niveau complète n’est pas possible. EG Secure Solutions précise que ce correctif est également disponible pour les versions en fin de vie.
Pour les environnements qui ne peuvent pas être mis à jour ou corrigés immédiatement, le JPCERT/CC indique que la désactivation de la fonction de statistiques empêche l’exposition à cette vulnérabilité. Il faut considérer cette mesure comme une solution de contournement temporaire, et non comme une raison de laisser indéfiniment en place une version vulnérable.
Le JPCERT/CC recommande également d’envisager une investigation visant à déterminer si les systèmes concernés ont été compromis, car leur exploitation a déjà été observée.
Ce que les équipes de sécurité doivent faire dès maintenant
Une réponse pratique ne nécessite pas d’attendre la publication d’un code d’exploitation ou de nouveaux éléments sur les attaquants.
Commencez par dresser l’inventaire des systèmes équipés de SiteGuard Server Edition, puis :
- Vérifier la version et la plate-forme installées.
- Confirmer si la fonction de statistiques est activée.
- Télécharger et préserver les informations de diagnostic avant de modifier l’installation.
- Rechercher les signes de compromission sur les systèmes concernés.
- Mettre à niveau vers la version corrigée ou appliquer le correctif de l’éditeur.
- Désactiver les statistiques comme solution de contournement temporaire si une remédiation immédiate n’est pas possible.
- Vérifier à nouveau les systèmes après la remédiation afin de confirmer qu’ils exécutent une version corrigée.
EG Secure Solutions indique que les clients bénéficiant de contrats d’assistance directe ont été informés de la vulnérabilité et des contre-mesures le 29 septembre, tandis que l’avis public a été publié le 14 octobre. L’éditeur n’a pas révélé quand l’exploitation avait commencé, qui en était à l’origine ni combien de systèmes avaient été compromis.
Ces inconnues ne changent rien à la réponse immédiate. La fonction de statistiques est activée par défaut, l’exploitation est confirmée et la remédiation elle-même peut supprimer des éléments de preuve utiles. Préservez d’abord les éléments de diagnostic, puis neutralisez la voie vulnérable.
À lire également : une vulnérabilité de prise de contrôle du serveur récemment corrigée par GitLab, avec un score CVSS de 10,0.