Une faille critique a récemment été identifiée dans Imunify360 AV, un outil d’analyse de sécurité déployé par des hébergeurs pour protéger plus de 56 millions de sites web. L’avis publié par la société de cybersécurité Patchstack indique que cette vulnérabilité permettrait à des attaquants d’obtenir le contrôle complet du serveur et de l’ensemble des sites qui y sont hébergés.

Imunify360 AV : rôle et portée du scanner

Imunify360 AV est un système de détection de logiciels malveillants utilisé par plusieurs fournisseurs d’hébergement. L’anomalie a été repérée dans le moteur de détection nommé AI-Bolit (parfois orthographié Ai-Bolit) et affecte également le module dédié à l’analyse des bases de données. Comme le problème concerne à la fois le scanner de fichiers et le scanner de base de données, les attaquants disposent de deux vecteurs distincts pour compromettre un environnement, ce qui peut déboucher sur une prise de contrôle complète du serveur et exposer potentiellement des millions de sites.

Patchstack a publié des informations techniques sur l’impact possible via son rapport (détails de l’analyse) :

« Des attaquants à distance peuvent insérer du PHP spécialement fabriqué et obfusqué correspondant aux motifs de déobfuscation d’imunify360AV (AI-Bolit). Le déobfuscateur extrait et exécute des fonctions sur des données contrôlées par l’attaquant, autorisant l’exécution de commandes système arbitraires ou de code PHP arbitraire. L’impact peut aller d’une compromission isolée de site à une prise de contrôle complète du serveur, en fonction de la configuration d’hébergement et des privilèges.

La détection est difficile car les charges utiles malveillantes sont fortement obfusquées (échappements hexadécimaux, paquets compressés, enchaînements base64/gzinflate, transformations personnalisées), et sont justement destinées à être déobfusquées par l’outil lui‑même.

imunify360AV (Ai-Bolit) est un scanner spécialisé dans les fichiers liés aux sites web (php/js/html). Par défaut, le scanner s’exécute en tant que service et fonctionne avec des privilèges élevés.

Escalade sur hébergement mutualisé : sur un environnement mutualisé, l’exploitation réussie peut conduire à une élévation de privilèges et à l’obtention d’un accès root selon la manière dont le scanner est déployé et les privilèges attribués. Si imunify360AV ou son wrapper s’exécutent avec des privilèges élevés, un attaquant peut tirer parti d’une exécution de code à distance (RCE) pour passer d’un site compromis unique au contrôle complet de l’hôte. »

La spécificité architecturale du scanner — sa capacité à déobfusquer et à exécuter du code détecté — est précisément ce qui permet l’exploitation : une fois que le moteur interprète et transforme une charge utile malveillante, il risque de lancer des fonctions contrôlées par l’attaquant avec les privilèges dont il dispose.

Dans les configurations où le scanner s’exécute avec des droits élevés, une simple charge utile injectée peut migrer d’une compromission au niveau d’un site vers un contrôle global du serveur. Ce lien entre déobfuscation, niveau de privilège et exécution explique que Patchstack estime l’impact potentiellement maximal, jusqu’à la prise de contrôle totale.

Deux vecteurs vulnérables : scanner de fichiers et scanner de base de données

Les premiers travaux des chercheurs ont révélé une faille dans le scanner de fichiers. Par la suite, il est apparu que le module d’analyse des bases de données présentait une vulnérabilité de même nature. Selon l’annonce technique : « le scanner de base de données (imunify_dbscan.php) était également vulnérable, et vulnérable de la même manière. » Les deux composants transmettent du code potentiellement malveillant aux routines internes d’Imunify360, qui peuvent alors exécuter ce code non fiable, offrant ainsi à un attaquant deux manières distinctes de déclencher l’exploitation.

Concrètement, le premier chemin d’attaque implique le dépôt d’un fichier spécialement conçu sur le serveur dans un emplacement que le scanner analysera. Le second chemin — via la base de données — se contente de la capacité à écrire dans la base, ce qui est beaucoup plus fréquent sur des environnements d’hébergement mutualisé.

Pourquoi cette vulnérabilité est facile à exploiter

Le scanner de fichiers exige qu’un fichier malveillant soit injecté quelque part dans l’arborescence analysée, ce qui suppose au minimum la possibilité d’uploader ou de créer un fichier. En revanche, le scanner de base de données ne demande que la possibilité d’écrire une entrée en base, une capacité commune sur la plupart des sites web dynamiques.

Des fonctions d’interaction usuelles — formulaires de commentaire, formulaires de contact, champs de profil, journaux de recherche, etc. — peuvent enregistrer du contenu en base de données sans authentification stricte. Si ces points d’entrée ne sont pas correctement filtrés, un attaquant peut y insérer du contenu obfusqué qui sera ultérieurement relu et analysé par le scanner, menant à une exécution de code à distance (RCE). Ainsi, une saisie utilisateur courante peut se transformer en vecteur pour une compromission à l’échelle de l’hôte.

Cette caractéristique élargit la portée du risque : la faille n’est pas limitée aux vecteurs classiques d’injection de fichiers, mais s’étend à toute fonctionnalité capable d’écrire en base, ce qui est particulièrement problématique sur des environnements partagés où plusieurs sites cohabitent et partagent des composants communs.

Silence du fournisseur et chronologie de divulgation

D’après Patchstack, un correctif a été publié pour Imunify360 AV, mais aucun communiqué public détaillé n’a été émis par l’éditeur et aucun identifiant CVE (Common Vulnerabilities and Exposures) n’aurait été attribué à la faille à la date du rapport. Un CVE fournit une référence publique standardisée qui permet de cataloguer une vulnérabilité et d’informer les parties prenantes en matière de gestion des risques. L’absence de CVE complique la diffusion de l’information, même si la fiche correspondant à l’incident est disponible publiquement sur le système de support Zendesk d’Imunify360.

Extrait du rapport de Patchstack :

« Cette vulnérabilité est connue depuis la fin octobre, et des notifications ont commencé à être envoyées aux clients peu après. Nous recommandons aux fournisseurs d’hébergement affectés d’obtenir plus d’informations du fournisseur concernant d’éventuelles exploitations dans la nature ou les résultats d’enquêtes internes.

Malheureusement, l’équipe d’Imunify360 n’a pas publié de déclaration publique sur le sujet, et aucun CVE n’a encore été attribué. Parallèlement, l’information est disponible publiquement sur leur Zendesk depuis le 4 novembre 2025.

Sur la base de notre analyse de cette vulnérabilité, nous estimons que le score CVSS pertinent est : 9.9 »

Le manque de communication publique et l’absence initiale d’un CVE standardisé peuvent retarder la prise de conscience du risque par certains administrateurs ou clients, augmentant la fenêtre durant laquelle des environnements vulnérables restent exposés.

Mesures recommandées pour les administrateurs et pistes d’atténuation

Face à une vulnérabilité de ce type, plusieurs mesures techniques et organisationnelles sont pertinentes pour réduire rapidement l’exposition et limiter les risques. Les options suivantes sont présentées à titre informatif plutôt que comme impératifs directs :

• Appliquer le correctif publié par l’éditeur lorsque cela est possible ; la version corrigée citée est antérieure à 32.7.4.0 (vérifier la version exacte du fournisseur).
• Si le déploiement immédiat d’une mise à jour n’est pas réalisable, envisager d’exécuter le scanner dans un environnement isolé (conteneur dédié, chroot, namespace, machine virtuelle) avec des privilèges réduits afin de limiter la portée d’une éventuelle exploitation.
• Restreindre au minimum les privilèges nécessaires pour l’exécution du scanner (principe du moindre privilège) et vérifier que l’outil ne tourne pas avec des droits root inutiles.
• Passer en revue les points d’entrée de l’application web susceptibles d’écrire en base de données (commentaires, formulaires publics, champs dynamiques) et y appliquer des contrôles renforcés : nettoyage des entrées (sanitization), validation stricte et codage des sorties.
• Sur les environnements partagés, limiter les interactions entre comptes et l’accès aux fichiers et bases d’un site par d’autres sites ou processus non autorisés.
• Examiner les journaux d’accès et d’audit pour détecter des activités anormales autour des dates connues de la divulgation : uploads inhabituels, requêtes contenant des motifs d’obfuscation (base64, gzinflate, séquences hexadécimales), exécutions de scripts inattendues.
• Mettre en place une surveillance des fichiers et des signatures (YARA, règles de détection personnalisées) pour repérer des charges utiles obfusquées ciblant la déobfuscation d’AI-Bolit.
• Considérer des contrôles de sécurité complémentaires sur l’hôte : AppArmor, SELinux, listes blanches d’applications, et séparation stricte des comptes systèmes.

Selon le rapport initial, les hébergeurs concernés auraient commencé à recevoir des notifications dès la découverte. La coordination entre équipes d’exploitation, équipes de sécurité et fournisseurs de l’outil demeure une composante essentielle d’une réponse adaptée.

Détection d’une compromission potentielle : indicateurs à surveiller

Lorsque la menace consiste en une exécution de code à distance via des charges utiles déobfusquées, certains signes peuvent indiquer une intrusion ou une exploitation en cours :

• Présence de fichiers inattendus ou modifiés dans des répertoires web (webroot, dossiers d’uploads) ou fichiers PHP contenant des patterns d’obfuscation (base64, gzinflate, échappements hexadécimaux, fonctions eval() inhabituelles).
• Entrées en base de données contenant des blobs ou des chaînes manifestement encodées et destinées à être interprétées côté serveur.
• Processus ou exécutions inhabituelles lancées par le service d’Imunify360 AV ou par l’utilisateur sous lequel il s’exécute.
• Augmentation anormale du trafic sortant vers des IPs inconnues ou des connexions sortantes non attendues.
• Apparition de shells web (webshells), cron jobs créés par des comptes compromis, ou comptes systèmes récemment modifiés.
• Signaux d’escalade de privilèges : accès root inattendu, modification de fichiers système protégés, charges utiles exploitant des privilèges élevés.

En cas d’observation de tels éléments, il est pertinent d’engager une procédure d’analyse et d’investigation pour déterminer l’étendue de la compromission, identifier les vecteurs initiaux et définir les actions de confinement et de remédiation.

Approche de réponse et de remédiation après compromission

L’analyse post‑incident doit suivre des étapes structurées afin d’éviter la perte d’éléments de preuve et de réduire au minimum la fenêtre d’exposition :

• Collecte des logs et des artefacts : journaux systèmes, journaux d’accès web, journaux d’exécution du scanner, dumps de base de données, copies des fichiers suspects. Assurer la conservation hors ligne des éléments critiques.
• Isolation des systèmes compromis : déplacer les services affectés vers un réseau isolé ou mettre hors service temporairement les processus compromis pour prévenir toute propagation.
• Analyse forensique : examiner les fichiers suspects, corréler les événements dans le temps, identifier les comptes ou clefs utilisées pour l’attaque, rechercher des backdoors persistantes.
• Éradication : supprimer les backdoors, corriger les comptes compromis, appliquer correctifs et mises à jour, restaurer les fichiers à partir de sauvegardes saines lorsque cela est justifié.
• Vérification : passer en revue l’ensemble de l’environnement pour confirmer l’absence d’autres implants malveillants et valider que les mesures de réduction d’impact sont efficaces.
• Rapports et documentation : consigner la chronologie des événements, les actions entreprises et les leçons tirées pour améliorer la posture de sécurité.

Ces étapes peuvent nécessiter la coopération de plusieurs équipes (exploitation, sécurité, développement) et l’accès à ressources spécialisées en cas d’incident majeur.

Considérations spécifiques aux environnements mutualisés

Les infrastructures d’hébergement mutualisé présentent des caractéristiques qui augmentent la criticité de ce type de vulnérabilité :

• Multiples sites et comptes partagent le même hôte physique et, potentiellement, des services communs (scanners, agents, démons). Une faille dans un composant central peut affecter l’ensemble des locataires.
• Les processus ou services s’exécutant avec des privilèges supérieurs peuvent être utilisés par un attaquant pour escalader ses droits et accéder à des ressources qui ne devraient pas être exposées à un site individuel.
• La surface d’attaque est étendue : des milliers de sites différents peuvent disposer de points d’entrée variés (plugins, CMS, formulaires) susceptibles d’être exploités pour injecter du contenu en base de données ou déposer des fichiers malicieux.

Pour ces raisons, les opérateurs d’hébergement mutualisé privilégient généralement des mécanismes d’isolation forts (chroot, conteneurs dédiés, séparation des comptes système) et une surveillance rapprochée des agents natifs de sécurité tels qu’Imunify360 AV.

Communication, transparence et gestion des vulnérabilités

La découverte d’une vulnérabilité à fort impact met en lumière l’importance d’une communication claire et d’une gestion coordonnée des divulgations. Plusieurs éléments interviennent :

• Assignation d’un identifiant CVE : il facilite le suivi public et la corrélation des incidents à l’échelle sectorielle.
• Notifications coordonnées aux clients et administrateurs afin qu’ils puissent prendre des mesures appropriées en temps utile.
• Publication de recommandations techniques et de « patch notes » détaillés par l’éditeur pour permettre une application sûre des correctifs.

Selon les informations disponibles publiquement, l’éditeur a publié un correctif mais n’a pas, au moment du rapport, diffusé de communiqué public ni obtenu de CVE associé. Cette situation peut retarder la réaction de certains opérateurs moins connectés aux flux d’information technique spécialisés.

Ressources techniques et pratiques complémentaires

Pour renforcer la résilience face à des vulnérabilités similaires, les pratiques et outils suivants peuvent être utiles :

• Scanner et durcir les entrées utilisateur (WAF, règles mod_security, validation côté serveur).
• Règles de détection statique et dynamique pour repérer les motifs d’obfuscation et les chaînes encodées souvent utilisées pour dissimuler des charges utiles.
• Tests de sécurité réguliers (scans automatisés, pentests) axés sur les chemins d’injection de contenu et les privilèges d’exécution des agents de sécurité.
• Segmentation stricte des permissions sur le système de fichiers et les bases de données afin qu’une injection au niveau applicatif ne puisse pas être facilement propagée par un composant tiers.
• Politique de mise à jour et de gestion des correctifs pour les outils tiers, avec phases de test et déploiement contrôlé.

Conclusion : compréhension du risque et préparation

La découverte de la faille dans Imunify360 AV/AI-Bolit illustre comment une fonctionnalité conçue pour améliorer la sécurité — la capacité à déobfusquer et analyser des charges utiles — peut devenir un vecteur d’exploitation si elle est elle‑même vulnérable. Le fait que le problème affecte à la fois le scanner de fichiers et le scanner de base de données étend la surface d’attaque et accroît la criticité, notamment sur des plateformes d’hébergement mutualisé.

Les propriétaires d’environnements hébergés et les administrateurs système disposent d’un éventail de mesures techniques pour réduire l’exposition : application des correctifs, limitation des privilèges, isolation des processus, renforcement des contrôles d’entrée et mise en œuvre d’une surveillance adaptée. Parallèlement, la coordination entre fournisseurs, équipes d’exploitation et communautés de sécurité, ainsi que la publication d’informations normalisées (par exemple via un CVE), améliorent la capacité collective à répondre à de tels incidents.

Featured Image by Shutterstock/DC Studio