En bref

  • Des attaquants ont détourné le routage BGP de l'infrastructure de mises à jour Softaculous pour injecter un payload malveillant dans Virtualizor, un logiciel de gestion VPS déployé chez des milliers d'hébergeurs.
  • L'attaque, active du 28 au 30 août 2026, a ciblé les serveurs hyperviseurs de fournisseurs d'hébergement ayant vérifié des mises à jour pendant la fenêtre d'interception BGP.
  • Softaculous a publié la version 3.2.9.9 de Virtualizor avec des correctifs et prévoit d'implémenter la signature cryptographique des paquets, jusqu'ici absente du mécanisme de mise à jour.

Comment une attaque BGP a transformé les mises à jour Virtualizor en vecteur d'infection

Le 2 septembre 2026, BleepingComputer et Cybersecurity News ont révélé les détails techniques d'une attaque sophistiquée menée contre l'infrastructure de mise à jour de Softaculous, l'entreprise derrière Virtualizor, un panneau de gestion de serveurs virtuels (VPS) largement déployé chez les hébergeurs web. L'incident, qui s'est déroulé entre 20h57 UTC le 28 août et 06h10 UTC le 30 août, illustre une variante rare et particulièrement dangereuse d'attaque supply chain : le détournement BGP ciblé pour substituer des paquets logiciels légitimes par des versions compromises.

Le Border Gateway Protocol (BGP) est le protocole de routage inter-domaine qui gouverne la façon dont les paquets Internet transitent entre les systèmes autonomes (AS) des différents opérateurs. Son architecture, conçue dans les années 1980 pour la fiabilité avant la sécurité, repose sur la confiance entre pairs : un AS peut annoncer des préfixes d'adresses IP à ses voisins, et si ces annonces ne sont pas filtrées, elles peuvent prendre le dessus sur les routes légitimes.

C'est précisément ce mécanisme qu'ont exploité les attaquants. Softaculous héberge ses serveurs de mise à jour et de facturation sur un bloc d'adresses IP de l'hébergeur allemand Hetzner, appartenant au préfixe 162.55.0.0/16. Les attaquants ont contrôlé ou compromis l'AS62390 (NexonHost) pour faire annoncer le préfixe plus spécifique 162.55.80.0/24 via l'AS6204 (Zet.net). En routage BGP, le préfixe le plus spécifique l'emporte : tout le trafic destiné aux adresses du bloc /24, incluant les serveurs de mise à jour de Softaculous, a été redirigé vers l'infrastructure contrôlée par les attaquants, sans que Hetzner ni Softaculous ne le détectent immédiatement.

Pour que la substitution soit transparente, les attaquants ont mis en place un serveur web capable de servir une fausse mise à jour Virtualizor avec un certificat TLS valide — probablement obtenu via une autorité de certification automatisée comme Let's Encrypt, en profitant de la fenêtre durant laquelle le trafic DNS était également sous leur contrôle. Les serveurs Virtualizor qui ont contacté le serveur de mise à jour pendant la fenêtre d'interception ont reçu un paquet malveillant accepté par le client de mise à jour.

La faille fondamentale exploitée côté Virtualizor est l'absence de vérification cryptographique des paquets de mise à jour. Virtualizor s'appuyait uniquement sur la validation TLS du transport — un niveau de sécurité insuffisant face à un scénario où l'attaquant contrôle le point de terminaison TLS. Sans signature cryptographique des paquets par Softaculous avec une clé privée dont seuls eux détiennent le secret, rien n'empêche un serveur intermédiaire de substituer le contenu. Le payload malveillant a été exécuté avec les privilèges root, niveau d'accès que Virtualizor requiert pour gérer les hyperviseurs KVM, Xen, LXC, OpenVZ et Proxmox.

L'impact potentiel de cette attaque est amplifié par l'architecture même de Virtualizor : un serveur master peut contrôler des centaines de nœuds de virtualisation. Un attaquant obtenant un accès root sur le master bénéficie d'une position de pivot idéale pour compromettre l'ensemble des serveurs VPS hébergés sur l'infrastructure. Les hébergeurs utilisant Virtualizor pour vendre des VPS à leurs propres clients ont donc potentiellement exposé leurs clients finaux à des risques de compromission en cascade, faisant de cet incident un problème de supply chain à plusieurs niveaux.

Selon Softaculous, seul un nombre limité d'installations a reçu la mise à jour malveillante — celles qui ont vérifié les mises à jour pendant la fenêtre de 33 heures d'interception BGP. L'entreprise a immédiatement signalé le certificat frauduleux pour révocation aux autorités de certification concernées et a collaboré avec les équipes de sécurité de Hetzner pour rétablir le routage légitime. La version 3.2.9.9 de Virtualizor, publiée le 1er septembre, inclut un outil Security Analyzer dans le panneau d'administration pour permettre aux hébergeurs de vérifier l'intégrité de leur installation.

La nature exacte du payload malveillant — backdoor persistant, collecte de credentials, préparation d'une attaque ultérieure — n'a pas encore été divulguée publiquement par Softaculous à la date du 2 septembre. Cette absence de détails techniques laisse de nombreux hébergeurs dans l'incertitude sur l'étendue réelle de la compromission subie, et augmente l'urgence d'une vérification forensique complète pour ceux ayant reçu des mises à jour pendant la période d'interception.

BGP hijacking et supply chain : une combinaison redoutable encore sous-estimée

L'attaque contre Virtualizor appartient à une catégorie d'incidents qui reste relativement rare mais dont la sophistication et l'impact potentiel la placent parmi les menaces les plus sérieuses pour l'infrastructure Internet. La combinaison du détournement BGP avec la compromission de la chaîne d'approvisionnement logicielle représente un vecteur d'attaque que peu d'organisations sont en mesure de détecter en temps réel, faute d'outillage de monitoring BGP ou de systèmes de vérification d'intégrité des paquets logiciels.

Le précédent le plus célèbre de détournement BGP à des fins malveillantes reste celui de 2018, quand le trafic DNS d'Amazon Route 53 a été redirigé pendant deux heures pour voler des cryptomonnaies. Mais l'utilisation du BGP hijacking spécifiquement pour compromettre une chaîne de mise à jour logicielle est plus rare et plus dangereuse. Elle rappelle, dans son concept, la compromission de SolarWinds Orion en 2020 — infiltrer la distribution logicielle plutôt que les systèmes finaux directement — avec la couche supplémentaire d'une manipulation du routage Internet en amont.

La protection contre ce type d'attaque passe par deux familles de mesures complémentaires. Côté réseau, le déploiement de RPKI (Resource Public Key Infrastructure) permet aux détenteurs de blocs IP de signer cryptographiquement leurs annonces de routes, rendant les détournements BGP détectables et bloquables par les opérateurs qui valident ces signatures. Mais l'adoption de RPKI reste incomplète à l'échelle mondiale, notamment dans certaines régions où les pratiques de peering sont moins strictes. Côté logiciel, la signature cryptographique des paquets par les éditeurs, avec vérification côté client avant l'installation, est la mesure qui aurait directement neutralisé cette attaque — et elle reste absente de nombreux mécanismes de mise à jour automatique, même en 2026.

Pour les hébergeurs utilisant des outils de gestion VPS comme Virtualizor, cet incident est un rappel brutal que la sécurité de l'infrastructure d'hébergement va bien au-delà des configurations individuelles des serveurs. La dépendance à des mécanismes de mise à jour automatique non signés cryptographiquement constitue un risque systémique qui peut transformer un outil d'administration en vecteur de compromission massive. Les fournisseurs d'hébergement mutualisé et VPS doivent auditer leurs dépendances logicielles tierces et exiger des garanties contractuelles sur la sécurité des processus de distribution, incluant la signature des paquets et les mécanismes de vérification d'intégrité.

Ce qu'il faut retenir

  • Des attaquants ont utilisé le BGP hijacking pour rediriger les mises à jour Virtualizor vers un serveur malveillant pendant 33 heures fin août, exploitant l'absence de signature cryptographique des paquets.
  • Les hébergeurs ayant utilisé Virtualizor entre le 28 et le 30 août doivent vérifier l'intégrité de leur installation via le Security Analyzer inclus dans la version 3.2.9.9 et auditer leurs journaux système.
  • Cet incident rappelle l'urgence de déployer RPKI pour sécuriser les annonces BGP et d'imposer la signature cryptographique des paquets dans tous les mécanismes de mise à jour logicielle automatique.

Comment savoir si mon serveur Virtualizor a reçu la mise à jour malveillante ?

Softaculous recommande d'utiliser le Security Analyzer intégré à la version 3.2.9.9 pour vérifier l'intégrité des fichiers installés. Comparez les hashes des binaires Virtualizor avec ceux publiés sur le blog officiel de Virtualizor. Consultez également les journaux système (/var/log/syslog, /var/log/auth.log) pour identifier des connexions ou exécutions de processus inhabituels entre le 28 et le 30 août 2026. En cas de doute, une réinstallation complète depuis les sources officielles vérifiées reste la mesure la plus sûre, en conservant une copie des journaux pour une analyse forensique ultérieure.

Besoin d'un accompagnement expert ?

Ayi NEDJIMI vous accompagne sur vos projets cybersécurité et IA.

Prendre contact