EN
en direct

Un détournement BGP a livré une mise à jour Virtualizor malveillante à des serveurs de production

Entre le 28 et le 30 août 2026, des attaquants ont détourné la plage 162.55.80.0/24 de Softaculous pour faire livrer une mise à jour Virtualizor piégée à des hyperviseurs. Tout exploitant de Virtualizor doit vérifier la présence du service java-jre-update.service, pivoter ses clés et exiger des mises à jour signées.

Un échangeur autoroutier sombre vu de nuit, une flèche ambre détournant une seule file de trafic.

28 août 2026, 20 h 57 UTC. 29 août, 10 h 33 UTC. 30 août, 6 h 10 UTC. Pendant 33 heures, des attaquants ont détourné une plage de 256 adresses IP appartenant à Softaculous, l’éditeur émirati de Virtualizor, pour faire livrer une mise à jour logicielle piégée à des hyperviseurs en production. 5 serveurs sur 34. C’est le nombre de machines où un fournisseur d’infrastructure a confirmé une compromission racine. Pourquoi c’est important : la route annoncée était valide selon RPKI, et le paquet n’était pas signé. Le détournement BGP n’a eu besoin de contourner ni l’un ni l’autre.

Ce qui s’est réellement passé

Le vecteur est une attaque de chaîne d’approvisionnement classique, mais son point d’entrée n’a rien de classique. Plutôt que de compromettre les serveurs de build de Softaculous, les attaquants ont détourné le routage qui mène à ses serveurs de mise à jour. La plage 162.55.80.0/24, un sous-ensemble de 162.55.0.0/16 normalement originaire de Hetzner (AS24940), a été annoncée le long du chemin AS6204 (Zet.net), AS62390 (Nexon Host) puis AS24940. Pendant la fenêtre d’incident, un serveur Virtualizor dont le trafic était dévié pouvait recevoir un paquet de mise à jour malveillant depuis le serveur de l’attaquant.

Le détail qui rend l’affaire instructive, c’est que la route passait la validation RPKI. Selon Doug Madory, responsable de l’analyse Internet chez Infoblox et auteur d’une rétrospective publiée chez Kentik, l’attaquant a ajouté 24940 comme dernier ASN du chemin, ce qui rendait l’annonce conforme à la ROA : celle-ci exigeait l’origine AS24940 et autorisait une longueur de préfixe comprise entre /16 et /24. Une route RPKI-valide n’est pas une route légitime — elle est seulement une route qui coche une case.

Deux failles qui se cumulent

L’attaque repose sur l’empilement de deux défaillances indépendantes, dont aucune n’est sophistiquée.

La première est la configuration laxiste du routage chez Hetzner. L’hébergeur a laissé les attaquants dévier le trafic par intermittence sur deux séquences distinctes dans une fenêtre de 33 heures. Il a récupéré l’espace 12 heures après le début du détournement en annonçant le bon chemin, puis a cessé d’annoncer ce chemin — ce qui a permis à l’attaquant de réitérer le détournement une seconde fois. Cette fois, il a fallu près de 10 heures pour réagir. Ben Cartwright-Cox, créateur de la suite BGP Tools, qualifie ces manquements de « erreurs bêtes et évitables ».

La seconde est l’absence de signature de code. Softaculous l’admet explicitement dans son avis de sécurité : les clients de mise à jour de Virtualizor ne vérifiaient pas cryptographiquement les paquets. Un paquet modifié n’était donc rejeté sur aucune base. C’est la brique qui aurait dû rendre le détournement inoffensif : sans signature, le premier qui contrôle la route contrôle le code.

L’indicateur de compromission à chercher

Softaculous ne peut pas produire la liste exhaustive des serveurs touchés, précisément parce que le trafic de mise à jour était détourné vers l’attaquant et que les journaux n’existent pas côté éditeur. Il recommande donc de traiter chaque serveur Virtualizor comme potentiellement concerné. L’indicateur publié est un service systemd inhabituel :

bash
# 1. Le service malveillant rapporté par Softaculous
ls -l /etc/systemd/system/java-jre-update.service
systemctl list-unit-files | grep -i java-jre-update
systemctl status java-jre-update 2>/dev/null

# 2. Si présent : pivot des accès avant tout audit
#    - révoquer et restreindre les clés API Virtualizor/Softaculous
#    - auditer les clés SSH autorisées, les comptes et les cron
#    - inspecter les connexions sortantes

# 3. Audit rapide de l'activité récente
last -20
crontab -l
cat /root/.ssh/authorized_keys

La présence de ce service n’est pas une preuve de compromission, mais elle déclenche un pivot immédiat des identifiants et un audit complet : clés SSH, comptes, tâches planifiées et connexions sortantes. Les utilisateurs qui ont accédé à l’espace client Softaculous ou saisi des données de paiement pendant la fenêtre doivent réinitialiser leur mot de passe et surveiller leurs relevés.

La réponse de l’éditeur

Softaculous a publié le 1er septembre 2026 la version 3.2.9.9 de Virtualizor, qui embarque un outil « Security Analyzer » dans le panneau d’administration. L’éditeur annonce aussi la mise en place d’une signature cryptographique pour tous ses paquets logiciels et une migration vers une infrastructure plus robuste. Ce sont les deux bonnes réponses, mais elles arrivent après coup : la signature de code est une exigence de base pour un canal de mise à jour, pas un correctif qu’on découvre à l’occasion d’un incident.

Le contraste avec l’état de l’art est net. Les écosystèmes sérieux — Debian, Arch, les paquets npm ou PyPI — signent leurs artefacts, et les clients vérifient la signature avant toute exécution. Un panneau de gestion de VPS qui pilote des hyperviseurs sans cette brique est une anomalie en 2026, pas une limitation acceptable.

Ce que RPKI ne règle pas

L’affaire doit corriger une idée reçue : RPKI ROV (Route Origin Validation) n’est pas une protection contre ce type d’attaque quand la ROA est permissive. Elle empêche l’annonce d’un préfixe par une origine non autorisée ; elle ne dit rien de la légitimité du contenu livré à travers une route valide. Deux couches manquent, et ce sont elles qui auraient contenu l’incident.

La première est l’ASPA (Autonomous System Provider Authorization), encore peu déployée, qui vérifie la légitimité du chemin complet plutôt que de la seule origine. La seconde est la surveillance des annonces : Softaculous, Hetzner et Zet.net n’ont détecté le détournement qu’après 22 heures d’aller-retour, faute de monitoring de leurs propres préfixes. Un opérateur qui annonce des blocs doit surveiller leur apparition dans la table de routage globale — c’est le signal le plus simple à instrumenter et le premier qui a fait défaut ici.

Un vecteur vieux de vingt ans qui revient par la négligence

Le détournement de préfixe n’est pas une nouveauté — il accompagne Internet depuis ses débuts, quand BGP fonctionnait sur la seule confiance. Les exemples documentés couvrent tout le spectre des acteurs : des groupes liés à des États, comme le détournement de trafic financier attribué à un opérateur russe en 2017, ou des opérations mercenaires, comme celle de Hacking Team en 2015 qui détournait des IP qu’elle ne possédait pas. Le cas le plus parlant reste celui de 2022 : trois heures d’inaction d’Amazon ont suffi à des attaquants pour détourner des adresses du géant, héberger un smart contract et siphonner environ 235 000 dollars en bitcoin à des utilisateurs du pont Celer.

Ce qui change dans l’affaire Softaculous, c’est la cible : non plus de la cryptomonnaie ou de l’espionnage ponctuel, mais un canal de mise à jour de logiciel. Le détournement BGP ne sert plus seulement à voler du trafic — il sert à fabriquer de la confiance, puis à la vendre sous forme de mise à jour. C’est un changement de nature, pas seulement d’échelle.

Verdict

Si vous exploitez Virtualizor, cherchez immédiatement le service java-jre-update.service, pivotez vos clés API et vos identifiants, et passez en 3.2.9.9. Ne considérez pas l’absence du service comme une innocuité : un attaquant peut avoir nettoyé ses traces. Auditez.

Si vous opérez un AS ou un hébergeur, déployez RPKI ROV et ajoutez une surveillance de vos annonces — mais ne vous arrêtez pas là : exigez la signature de code de chaque éditeur dont vous distribuez les mises à jour, et refusez les canaux non signés. La route valide est nécessaire, pas suffisante.

Si vous consommez des mises à jour automatiques en production, la leçon est universelle : épinglez les versions, vérifiez les signatures, et traitez tout canal de mise à jour comme une surface d’attaque à part entière. Le prochain éditeur sans signature de code n’est pas une hypothèse — c’est une liste de serveurs en attente.

Références

Le brief cyber, chaque mardi

Les failles qui comptent, les correctifs à appliquer, en dix minutes de lecture.

Pas de spam. Désinscription en un clic.
à lire ensuite

Sur le même sujet

Wi-Fi 8 arrête la course au débit pour viser la fiabilité

Le Wi-Fi 8 (IEEE 802.11bn) est la première génération sans fil qui ne cherche plus à battre un record de débit : à même vitesse théorique que le Wi-Fi 7, il vise une latence bornée et une fiabilité « ultra haute » en environnement dense. Les premiers produits Qualcomm et Broadcom arrivent fin 2026, mais l’utilisateur lambda peut s’en passer jusqu’en 2028.

← Retour au fil

Tapez au moins deux caractères.

naviguer ouvrir esc fermer