BGP détourné : certificat valide, puis accès root

Un détournement de 33 heures du trafic de Softaculous lui-même

Entre 20h57 UTC le 28 août et 06h10 UTC le 30 août 2026, un attaquant a détourné le routage BGP d'un bloc d'adresses IP hébergées chez Hetzner et appartenant à Softaculous, l'entreprise derrière le panneau de contrôle VPS Virtualizor, largement utilisé. Le réseau frauduleux AS62390, opérant sous le nom NexonHost, a annoncé une route plus spécifique pour le bloc 162.55.80.0/24 que l'annonce de Hetzner lui-même. Softaculous s'appuie sur Hetzner pour l'infrastructure derrière les serveurs de licences, de mises à jour et de téléchargement de Virtualizor, ce qui a précisément rendu le bloc détourné intéressant pour un attaquant.

Selon les règles standard de sélection de routes BGP, la route la plus spécifique l'emporte partout où elle est acceptée, si bien que le trafic destiné aux serveurs de Softaculous a été redirigé vers l'infrastructure de l'attaquant pendant environ 33 heures. BleepingComputer et The Register ont tous deux rapporté le détournement le 1er septembre 2026, et Softaculous a ensuite confirmé la chronologie et les détails techniques dans son propre rapport d'incident. Cybersecuritynews.com et GBHackers ont publié des articles corroborant ces faits le même jour, décrivant le détournement comme un cas d'école d'attaque par préfixe plus spécifique contre l'espace d'adressage d'un hébergeur.

Pourquoi le certificat n'a jamais déclenché d'alerte

Le détournement n'a pas seulement redirigé le trafic : il a aussi capturé les contrôles de validation de domaine que Let's Encrypt utilise pour confirmer qui contrôle un domaine, ce qui a permis à l'attaquant de demander et d'obtenir un certificat TLS réel et validement signé pour le domaine détourné. Les connexions au serveur de l'attaquant n'affichaient aucune alerte de certificat, car pour l'autorité de certification, la demande semblait venir du propriétaire légitime du domaine. Ni le cadenas du navigateur, ni la chaîne de certification, ni la connexion elle-même ne signalaient quoi que ce soit d'anormal.

C'est la partie gênante de cet incident : la validation automatisée de Let's Encrypt a fonctionné exactement comme prévu. Elle vérifie que celui qui répond à une adresse IP contrôle le domaine, et pendant la fenêtre de détournement, l'attaquant répondait effectivement à cette adresse. La falsification ne résidait pas dans le certificat, mais dans le routage qui décidait qui pouvait prouver la propriété. Cette distinction compte : renforcer la seule validation de domaine n'empêcherait pas une répétition, puisque la faiblesse se trouve dans la couche de routage sous-jacente.

Un client de mise à jour qui n'a jamais vérifié de signature

Un paquet de mise à jour malveillant de Virtualizor a été distribué à un petit nombre d'installations, précisément celles qui ont vérifié les mises à jour justement pendant la fenêtre de détournement, et non à l'ensemble des utilisateurs de Virtualizor. Le client de mise à jour de Virtualizor ne vérifie pas cryptographiquement les paquets qu'il télécharge, si bien qu'un certificat valide sur une route détournée a suffi à faire exécuter du code contrôlé par l'attaquant en tant que root sur les serveurs touchés. Virtualizor sert à gérer une grande partie de l'hébergement VPS d'entrée et de milieu de gamme dans le monde, ce qui explique pourquoi même une compromission limitée dans le temps a attiré l'attention de plusieurs médias spécialisés.

La charge utile a installé des clés SSH non autorisées et un faux service systemd déguisé en java-jre-update.service, donnant à l'attaquant une porte dérobée persistante capable de survivre à un redémarrage et de ressembler, à première vue, à une mise à jour Java ordinaire. Softaculous a publié la version corrigée Virtualizor 3.2.9.9 le 1er septembre 2026, accompagnée de son propre compte rendu de l'incident. Son avis recommande de rechercher à la fois les clés SSH intruses et le service déguisé par son nom, car la porte dérobée avait été conçue pour se fondre parmi les processus système légitimes.

Ce que les opérateurs européens doivent au titre de NIS2

Pour tout opérateur de l'UE ou du Royaume-Uni exploitant une infrastructure chez Hetzner ou chez un autre hébergeur européen, la leçon pratique est qu'un certificat HTTPS valide ne prouve pas l'authenticité lorsque le routage sous-jacent peut être falsifié. L'annonce de routes de Hetzner est restée correcte tout au long de l'incident ; la compromission résidait entièrement dans le trafic qui a choisi à la place la route plus spécifique de l'attaquant. Un mécanisme de mise à jour automatique qui ne vérifie pas les signatures est un point de défaillance unique, quelle que soit la solidité de l'infrastructure environnante. La même logique s'applique au-delà de Virtualizor, à tout produit qui récupère et installe du code automatiquement sans vérifier de signature cryptographique.

La remédiation recommandée pour quiconque utilise Virtualizor, ou le client de mise à jour automatique d'un autre fournisseur sans vérification de signature, est simple : faire tourner et restreindre les identifiants API, et auditer les serveurs à la recherche de clés SSH, de comptes, de tâches planifiées et de connexions sortantes non autorisées. En vertu de NIS2, les entreprises de l'UE qui dépendent de logiciels tiers pour des infrastructures critiques ont des obligations de diligence raisonnable sur leur chaîne d'approvisionnement, et un incident où le canal de mise à jour du fournisseur lui-même est devenu le vecteur d'attaque relève pleinement de cette obligation.

Pourquoi nous faisons cela

Nous faisons cela pour tous ceux qui essaient de suivre ce que la technologie fait à nos vies. Les personnes qui la construisent, et celles à qui elle arrive. Le Servola Journal existe pour que ce que nous apprenons appartienne à tous.

Personne ne nous paie pour cela. Pas de publicité, pas de paywall, gratuit pour tous. Nous croyons simplement que comprendre ce qui nous arrive à tous ne devrait pas dépendre de qui peut se permettre de payer pour cela.

Si cela vous a apporté quelque chose aujourd'hui, dites-nous de continuer. Suivez-nous, laissez un like ou écrivez un commentaire positif. Nous les lisons tous, et ce sont eux qui nous font avancer.

À lire ensuite: Aucun Régulateur UE Ne Contrôle L'Accès À Astra  |  Exploité Des Semaines Avant Que PaperCut Ne Corrige