Un détournement BGP livre un faux update

Ce qui se passe

Le 28 août 2026 à 20 h 57 UTC, l'AS 62390 (NexonHost) commence à annoncer 162.55.80.0/24 via le transitaire AS 6204 (Zet.net). Ce bloc appartient à Hetzner (AS 24940) et porte, entre autres, le point de terminaison de mise à jour de Softaculous et l'espace client.

L'annonce est plus spécifique que le 162.55.0.0/16 légitime : elle gagne la sélection de route partout où elle se propage. Le chemin d'AS conserve d'ailleurs Hetzner en queue, si bien que l'origine affichée reste correcte dans chaque relevé.

Un serveur imposteur, 162.55.80.8 — reverse DNS server.softaculous.com — répond alors à la place des vrais. Et comme la validation de propriété de domaine de Let's Encrypt emprunte elle aussi la route détournée, l'attaquant obtient un certificat TLS techniquement valide couvrant 24 noms, dont virtualizor.com, api.virtualizor.com et files.virtualizor.com. Aucun avertissement côté client.

Pourquoi ça a marché

Le TLS était la seule barrière : les clients de mise à jour des produits ne vérifiaient encore aucune signature cryptographique du paquet. Une fois le certificat obtenu, plus rien ne distinguait le paquet piégé de l'original. Virtualizor annonce désormais la mise en place d'une signature de code pour tous les paquets, et a publié la version 3.2.9.9 avec un outil d'atténuation.

L'ampleur, mesurée

Virtualizor a reconstruit l'incident à partir des données publiques du RIPE RIS, 368 pairs collecteurs, un instantané toutes les 10 minutes :

• fenêtre totale 33,3 h, en deux vagues (28/08 ~21 h → 29/08 08 h 50, puis 29/08 ~20 h → 30/08 ~06 h), séparées par ~11 h de calme ;
• au pic, ~72 % de l'ensemble des 368 pairs voyaient leur meilleur chemin passer par l'attaquant ; en moyenne pondérée sur la durée, ~28 % ;
• route très instable : ~10 600 retraits enregistrés sur la fenêtre.

Un serveur n'a reçu le paquet piégé que si sa vérification de mise à jour est tombée pendant un intervalle dérouté — d'où le faible nombre d'installations touchées. Mais comme les réponses malveillantes n'ont jamais atteint les journaux de l'éditeur, aucune liste définitive n'existe.

À retenir

1. Chercher l'indicateur de compromission : /etc/systemd/system/java-jre-update.service, et le service java-jre-update activé. S'il est présent, ne pas le supprimer — contacter l'éditeur pour préserver les preuves.
2. Réinitialiser toutes les clés d'API dans le panneau maître, restreindre l'accès API à des IP de confiance, supprimer les clés inconnues.
3. Auditer clés SSH, comptes, tâches cron et connexions sortantes inattendues. Script fourni : https://files.virtualizor.com/security/virtualizor_security_scan.sh
4. Si vous vous êtes connecté à softaculous.com/clients pendant la fenêtre, changez ce mot de passe et régénérez les clés d'API de l'espace client.

Source : Virtualizor