Un détournement BGP de 33 heures livre une mise à jour Virtualizor malveillante et un accès root persistant

28 août 2026, 20 h 57 UTC. Un réseau non lié commence à annoncer un bloc d’adresses IP Hetzner utilisé par Softaculous. 29 août. Le prestataire alerte Hetzner, puis une seconde vague reprend dans la soirée. 30 août, 6 h 10 UTC. La route malveillante est retirée. Pourquoi c’est important : pendant 33 heures, le trafic de mise à jour du panneau de contrôle Virtualizor a transité par un serveur attaquant, qui a livré un paquet malveillant et obtenu un accès root persistant sur au moins cinq hyperviseurs sur trente-quatre contrôlés.

Un détournement de routage devenu compromission de chaîne d’approvisionnement

Le point de départ est un mécanisme connu de longue date : la sélection de route BGP. Un annonceur malveillant a publié un préfixe plus spécifique que celui normalement annoncé par Hetzner pour les plages de Softaculous. Dans la logique de sélection de BGP, la route la plus spécifique l’emporte partout où elle est acceptée. Résultat : une partie du trafic destiné à l’éditeur a été redirigée vers un serveur contrôlé par l’attaquant, sans qu’aucune compromission d’infrastructure ne soit nécessaire.

Les systèmes touchés ne sont pas anecdotiques. Le détournement a frappé le point de terminaison de mise à jour de Virtualizor, ainsi que le site client et le site de facturation de Softaculous. L’attaquant a même obtenu un certificat TLS valide auprès de Let’s Encrypt, parce que la validation automatique de propriété du domaine passait elle aussi par la route détournée. Les connexions redirigées n’ont donc déclenché aucun avertissement de certificat — le point qui aurait dû alerter un administrateur a été neutralisé.

Un paquet non signé, un accès root persistant

La partie la plus grave n’est pas le détournement, mais ce qu’il a permis. Softaculous a confirmé qu’une mise à jour Virtualizor malveillante a été livrée à « une poignée » d’installations dont les contrôles de mise à jour passaient par le serveur attaquant. La raison est technique et tient en une phrase : « nos clients de mise à jour ne vérifiaient pas encore cryptographiquement les paquets, donc un paquet modifié n’aurait pas été rejeté sur cette base ».

Les conséquences sont mesurables. D’après The Hacker News, un fournisseur a constaté une compromission root sur cinq des trente-quatre hyperviseurs inspectés. L’indicateur de compromission publié par l’éditeur est une unité systemd : /etc/systemd/system/java-jre-update.service. Softaculous recommande de ne pas la supprimer immédiatement, mais de contacter l’éditeur pour préserver les preuves.

Une fenêtre de 72 % de probabilité d’exposition

L’ampleur du détournement se chiffre. Pendant chaque vague, Softaculous estime qu’un serveur donné avait environ 72 % de chances de se trouver sur un réseau acheminant la plage détournée par l’attaquant. Ce chiffre repose sur la proportion de collecteurs de routage RIPE portant la route hijackée, et non sur le volume de trafic réellement intercepté — il mesure l’exposition potentielle, pas le nombre de victimes confirmées.

La chronologie montre aussi une attaque qui « bat » comme un signal intermittent. La route a été acceptée par « quasiment tous les points de vue internet qui la reçoivent », puis a flappé à plusieurs reprises. Après le signalement à Hetzner vers 8 h 50 UTC le 29 août, le prestataire a annoncé directement le même préfixe plus spécifique, réduisant le détournement à presque zéro pendant 11 heures. La seconde vague est revenue vers 20 h UTC pour environ 10 heures, avant le retrait définitif entre 5 h 50 et 6 h 10 UTC le 30 août.

Pourquoi BGP reste la porte ouverte

L’incident n’est pas un accident de parcours : il appartient à une famille d’attaques qui persiste parce que le plan de contrôle de l’internet repose encore largement sur la confiance. La technique du préfixe plus spécifique exploite un arbitrage vieux comme le protocole lui-même — la route la plus précise gagne, sans que le réseau qui l’accepte vérifie que l’annonceur est légitime.

Le correctif existe pourtant : la validation d’origine de route (ROV, Route Origin Validation) adossée à l’infrastructure RPKI. En publiant des ROA (Route Origin Authorizations), un détenteur de préfixe déclare cryptographiquement quel AS est autorisé à l’annoncer ; un routeur qui applique la ROV rejette alors les annonces non autorisées. Le problème est l’adoption : la couverture ROV reste partielle à l’échelle mondiale, et une route malveillante n’a besoin que d’un seul chemin non filtré pour se propager. L’attaque contre Softaculous s’est appuyée précisément sur cette asymétrie.

Le contexte élargi dit que la pression ne retombe pas. Le 12 septembre 2026, le site de BGP.Exchange — une plateforme d’échange internet virtuelle — a été compromis et défiguré, un rappel que les acteurs du routage eux-mêmes sont des cibles. Quelques jours plus tôt, un incident BGP de plusieurs jours avait déjà paralysé le plan de contrôle national au Laos. Les détournements de routage ne sont plus des curiosités académiques : ils sont devenus un outil d’attaque opérationnel.

Ce que doit faire un opérateur de panneaux de contrôle

L’incident combine deux faiblesses structurelles que la plupart des hébergeurs partagent encore. La première est le routage, la seconde est la chaîne de mise à jour. Toutes deux se corrigent.

• Déployez la ROV RPKI chez votre transitaire. Le préfixe plus spécifique n’aurait pas été accepté par la plupart des pairs si la validation d’origine de route avait été active. Publiez vos ROA pour vos propres préfixes, et exigez de votre transitaire qu’il applique la ROV sur les routes qu’il reçoit.
• Signez vos paquets de mise à jour. La vérification cryptographique côté client — signature Ed25519, manifeste signé — aurait rejeté le paquet modifié indépendamment du routage. C’est la seule défense qui survit à un détournement réussi.
• Pivotez les secrets dans la fenêtre d’exposition. Mots de passe du client area, clés API Virtualizor, clés SSH inconnues, comptes ajoutés, tâches planifiées et connexions sortantes anormales : tout est à réinitialiser pour les serveurs actifs pendant la fenêtre.
• Traitez java-jre-update.service comme une preuve, pas comme un fichier à purger. Sa présence confirme la compromission ; la supprimer avant analyse détruit l’horodatage et l’origine de l’artefact.

Softaculous a de son côté invalidé les sessions du client area créées pendant l’incident et poursuit l’enquête sur ses autres produits — Backuply, SitePad, Webuzo — sans avoir identifié de paquet malveillant à ce jour.

Verdict

Ce détournement BGP est la démonstration la plus propre, depuis des années, qu’un problème de couche réseau peut se transformer en compromission de chaîne d’approvisionnement sans exploiter une seule faille logicielle. Si vous exploitez Virtualizor ou un panneau équivalent, cherchez java-jre-update.service avant toute autre action, puis pivotez les secrets et exigez de votre éditeur des mises à jour signées. Si vous êtes transitaire ou hébergeur amont, activez la ROV RPKI sur vos sessions de peering : c’est le seul maillon qui aurait coupé l’attaque à la racine. Si vous gérez un parc qui vérifie ses mises à jour sans signature, considérez que chaque mise à jour transitant par Internet est un vecteur ouvert — le prochain détournement n’attendra pas 33 heures pour livrer sa charge utile.

Références

• The Register — 33-hour BGP hijack of Softaculous traffic prompts security scramble, 1er septembre 2026
• The Hacker News — BGP Hijack Delivers Malicious Virtualizor Update That Establishes Persistent Root Access, 2 septembre 2026
• Virtualizor — Security Incident: BGP Hijacking
• Born City — BGP.Exchange Website Compromised, 12 septembre 2026
• ETTAYEB — Laos : quatre jours de panne BGP sur le plan de contrôle national