Une attaque par détournement BGP a redirigé le trafic de mise à jour de Softaculous et Virtualizor vers un serveur contrôlé par un pirate entre le 28 et le 30 août 2026, permettant ainsi à des paquets Virtualizor malveillants d’atteindre quelques installations. La leçon à en tirer est dérangeante : le protocole HTTPS ne permet de prouver que vous communiquez bien avec un domaine que si le routage et l’émission de certificats n’ont pas été altérés au préalable. Les systèmes de mise à jour nécessitent que les paquets signés, les contrôles de routage et les protections des référentiels fonctionnent de concert.
Que s'est-il passé lors de l'attaque par détournement BGP visant Softaculous ?
L'incident concernait l'adresse 162.55.80.0/24, une plage d'adresses IP hébergée par Hetzner et utilisée par l'infrastructure de Softaculous, notamment le point de terminaison de mise à jour de Virtualizor ainsi que les systèmes clients et de facturation de Softaculous. Selon Virtualizor et Softaculous, une annonce de route non autorisée a commencé vers 20 h 57 UTC le 28 août 2026, et le routage normal a été rétabli à l'échelle mondiale vers 06 h 10 UTC le 30 août.
Cette annonce non autorisée concernait l'AS62390, NexonHost, et le fournisseur de transit AS6204, Zet.net. L'origine légitime était l'AS24940, Hetzner. La route détournée étant un /24, elle était plus spécifique que la route plus large de Hetzner (162.55.0.0/16) ; de nombreux réseaux ont donc privilégié le chemin contrôlé par l'attaquant, conformément à la règle de correspondance du préfixe le plus long (LPPM) sur Internet.
Cela peut paraître obscur. Mais ce n'est pas le cas. Si votre serveur demandait une mise à jour de Virtualizor pendant ces périodes de redirection, certaines parties d'Internet pourraient envoyer cette requête au mauvais endroit, alors que le nom d'hôte semblerait toujours correct.
BleepingComputer a rapporté le 1er septembre 2026 que des paquets de mise à jour malveillants de Virtualizor avaient été diffusés au cours de cet événement. Virtualizor et Softaculous ont qualifié le groupe de victimes de « restreint », car seules les installations ayant vérifié la présence de mises à jour pendant le détournement et ayant reçu des réponses malveillantes ont été exposées.
La chronologie, avec les chiffres qui comptent
Le rapport d'incident de Virtualizor daté du 31 août 2026 a divisé l'événement en deux vagues distinctes. La première s'est déroulée du 28 août vers 21 h 00 UTC au 29 août à 08 h 50 UTC. La seconde s'est déroulée du 29 août vers 20 h 00 UTC au 30 août à 06 h 00 UTC, avec un retrait vers 06 h 10 UTC.
Un calcul utile : la durée totale de l’incident s’est élevée à environ 33 heures, mais les deux principales vagues d’activité totalisent environ 21 heures et 50 minutes. Cela représente environ les deux tiers de cette période. Pour les responsables de la sécurité, cette distinction est importante, car une simple indication temporelle indiquant que « l’incident a duré 33 heures » peut surestimer la durée d’exposition continue tout en sous-estimant le problème opérationnel : les vérifications de mise à jour sont automatisées, dispersées et faciles à manquer.
| Événement de 2026 | Détails communiqués | Pourquoi c'est important |
|---|---|---|
| 28 août, vers 20 h 57 UTC | AS62390 a commencé à annoncer l'adresse 162.55.80.0/24 | Le trafic vers les services Softaculous concernés pourrait être redirigé |
| 29 août, environ de 08 h 00 à 08 h 50 UTC | Virtualizor affirme que l'interception active a été confirmée par une source indépendante | Un serveur redirigé a répondu pour les domaines Softaculous disposant d'un certificat valide |
| 29 août, vers 08 h 50 UTC | Hetzner a commencé à annoncer directement l'adresse 162.55.80.0/24 | Selon Virtualizor, la déviation est tombée à zéro en quelques minutes |
| 30 août, vers 06 h 10 UTC | Itinéraire non autorisé supprimé | Le routage mondial normal a été rétabli |
| 1er septembre 2026 | Sortie de Virtualizor 3.2.9 Patch 9 | Ajout de l'outil « Security Analyzer » dans le panneau d'administration |
Virtualizor a indiqué avoir mesuré cet événement à l'aide de 368 pairs collecteurs du réseau RIPE RIS. Selon ses chiffres provenant d’une seule source, 368 pairs sur 368 ont acheminé la route détournée à un moment donné, avec un pic signalé à près de 1 001 TP7T de points de surveillance acheminant la route pendant les périodes d’activité, une médiane de 266 pairs et environ 10 600 retraits de route au cours de la période considérée.
Utilisez ces données avec prudence. Les nœuds RIPE RIS constituent des points d'observation, et non un recensement exhaustif de tous les serveurs concernés. Ils montrent néanmoins que cette fuite de routage n'était pas un simple incident local isolé. Elle s'est propagée à une échelle suffisamment large pour que le trafic lié aux mises à jour logicielles de routine devienne un vecteur de diffusion.
Pourquoi le protocole TLS n'a-t-il pas protégé le canal de mise à jour ?
On croit souvent à tort que le protocole HTTPS met fin à ce genre de situation. Dans le cas de Softaculous, l'attaquant aurait obtenu des certificats TLS techniquement valides lors du détournement, car le trafic de validation des certificats était également acheminé vers son serveur. Virtualizor a indiqué que le certificat couvrait des domaines tels que virtualizor.com, api.virtualizor.com et files.virtualizor.com.
Le protocole TLS protège la session de transport : la connexion est chiffrée, et le certificat associe un nom à une clé au sein du système d'autorité de certification. Mais si le processus permettant de prouver le contrôle du domaine est lui-même trompé par un détournement temporaire du routage, le navigateur ou le client de mise à jour peut ne signaler aucune erreur de certificat. Cadenas valide. Destination incorrecte.
Ars Technica a rapporté en septembre 2026 que Let’s Encrypt avait déclaré que la liaison de compte CAA aurait rendu la délivrance de certificats « nettement plus difficile » pour le pirate. Il s’agit là d’une mesure d’atténuation importante, mais pas d’un bouclier magique. Les contrôles des certificats réduisent le risque d’émission frauduleuse ; ils ne vérifient pas que la charge utile du logiciel soit bien celle que le fournisseur avait l’intention de distribuer.
Le piège gênant que de nombreuses analyses rétrospectives négligent : la surveillance a posteriori des certificats peut vous indiquer qu’un certificat suspect existait, mais elle ne vous dira pas nécessairement quels clients automatisés lui ont accordé leur confiance pendant une période de 20 minutes ou de deux heures au cours d’un événement de routage. À ce moment-là, votre programme de mise à jour aura peut-être déjà été exécuté en tant qu’administrateur.
La signature des paquets est la fonctionnalité qui manquait à Virtualizor
Virtualizor a indiqué que ses clients de mise à jour de produits ne vérifiaient pas encore cryptographiquement les paquets de mise à jour. Cela signifie qu’un paquet modifié n’aurait pas été rejeté pour cause de signature non valide une fois que le client aurait accepté le point de terminaison HTTPS. Honnêtement, pour un logiciel de gestion de serveurs, cette faille de sécurité est précisément ce qui devrait faire frémir les administrateurs.
A proper update design makes the client verify the payload independently from the connection. The client checks a vendor signature, a trusted signing key, signed metadata, or a pinned hash before installing. If the mirror, CDN, DNS path, or BGP route lies, the package still fails verification.
Il s'agit là de la même séparation des tâches que les équipes de sécurité appliquent déjà à la gestion des identités dans d'autres contextes. Si l'on considère les identifiants des machines et les identités des services, le problème général est similaire à celui décrit dans gestion des identités non humaines: les acteurs automatisés prennent des décisions à la vitesse d'une machine ; par conséquent, les hypothèses de confiance faibles ne sont pas adaptées à l'échelle.
La vérification du hachage peut à elle seule être utile, mais uniquement si le hachage de confiance provient d’un canal que l’attaquant ne peut pas modifier à son tour. Les métadonnées signées offrent une protection plus solide. Le cadre de mise à jour, connu sous le nom de TUF, va plus loin en proposant des rôles délégués, des signatures à seuil, une date d’expiration et une protection contre les annulations, de sorte qu’un miroir malveillant ne puisse pas simplement rejouer une ancienne version vulnérable ou mélanger des fichiers provenant de différentes versions.
Le rôle du BGP, du RPKI et du ROV dans la défense
Le protocole BGP a été conçu pour assurer l'accessibilité entre les réseaux coopérants, et non pour garantir la légitimité de chaque annonce de route. Une attaque de détournement BGP abuse de cette confiance en amenant Internet à privilégier un chemin non autorisé. La règle de correspondance du préfixe le plus long fait alors exactement ce pour quoi elle a été conçue : choisir la route la plus spécifique.
Le RPKI et la validation de l'origine des routes peuvent limiter les annonces d'origine non autorisées lorsque les autorisations d'origine des routes sont strictes et que les réseaux les appliquent rigoureusement. Dans ce cas précis, Ars Technica a rapporté, en citant Doug Madory, que le chemin AS falsifié restait valide selon le RPKI car la ROA exigeait l’origine AS24940 et autorisait des longueurs de préfixe allant de /16 à /24. Ce cas limite est important.
Traduction : disposer du RPKI ne revient pas à disposer d'une politique de routage qui bloque toutes les formes d'usurpation d'adresse utiles. Si un ROA autorise un /24 et que le chemin peut être rendu valide au niveau de l'origine, les défenseurs peuvent avoir besoin d'une surveillance supplémentaire, de limites maximales plus strictes pour la longueur des préfixes lorsque cela est possible, d'un filtrage en amont et d'une escalade rapide auprès des fournisseurs d'hébergement.
Pour les équipes qui prévoient d'héberger des services et d'assurer leur visibilité sur le réseau, la sécurité des routes de communication doit être prise en compte au même titre que la capacité et la géographie, et non reléguée dans une annexe oubliée. Ce même état d'esprit pratique s'applique lorsque vous planifier le déploiement d'un serveur dédié: familiarisez-vous avec les contrôles de routage, la procédure de notification et les contacts d'urgence de votre fournisseur avant qu'une panne ou un détournement ne se produise.
Que doivent vérifier dès maintenant les opérateurs de Virtualizor ?
Virtualizor et BleepingComputer conseillent tous deux aux opérateurs de vérifier si /etc/systemd/system/java-jre-update.service comme indicateur d'une éventuelle compromission. Softaculous a également conseillé aux utilisateurs de l'espace client de réinitialiser leurs mots de passe s'ils s'étaient connectés pendant les périodes concernées. Virtualizor ayant indiqué que des réponses malveillantes avaient été envoyées depuis le système de l'attaquant, la société n'a pas pu établir de liste définitive des serveurs affectés à partir de ses propres journaux.
Cela crée une situation délicate : si votre serveur a été mis à jour pendant cette période, le fait qu'il ne figure pas sur la liste d'un fournisseur ne garantit pas pour autant sa sécurité. Vous devez disposer de preuves locales.
- Vérifiez si
/etc/systemd/system/java-jre-update.serviceexiste, et de conserver les preuves judiciaires avant de supprimer quoi que ce soit. - Examinez l'historique des mises à jour de Virtualizor ainsi que les journaux système couvrant la période du 28 août à 20 h 57 UTC au 30 août à 06 h 10 UTC 2026.
- Installez Virtualizor 3.2.9 Patch 9, publié le 1er septembre 2026, puis lancez l'outil « Security Analyzer » depuis le panneau d'administration.
- Remplacez les identifiants qui auraient pu être utilisés lors de sessions client et de facturation concernées sur Softaculous ou Virtualizor.
- Effectuez une restauration à partir d'un support dont vous êtes sûr qu'il est intact si vous constatez l'indicateur ou si vous ne parvenez pas à déterminer ce qui s'est exécuté pendant la période concernée.
La correction automatisée est tentante, mais ne négligez pas la collecte des preuves. Si un hôte de gestion est compromis, il peut disposer d'identifiants permettant d'accéder à des machines invitées, à des modèles, au stockage, aux API DNS ou aux systèmes de sauvegarde. Les panneaux de contrôle des serveurs occupent des emplacements privilégiés.
Les équipes qui pratiquent déjà la simulation d'attaques devraient intégrer la compromission des canaux de mise à jour dans leurs scénarios. Si vous recourez aux tests autonomes, une étape utile consiste à modéliser la même chaîne décrite dans « red teaming » autonome: confiance dans les chemins d'accès, confiance dans les certificats, confiance dans les paquets et persistance après l'installation.
La véritable leçon : les mises à jour doivent s'accompagner d'une méfiance à plusieurs niveaux
A BGP hijacking attack like this one is not just a network story. It is a supply-chain story wearing a routing mask. The attacker didn’t need to breach every Virtualizor customer directly; the update mechanism did the distribution work for any client that asked at the wrong time.
Une bonne architecture part du principe que chaque couche peut présenter des défaillances pendant un certain temps. Le protocole TLS peut être valide sans pour autant être suffisant. Le protocole BGP peut faire l'objet d'une surveillance tout en étant brièvement détourné. Un référentiel peut être accessible tout en restant hostile. Les paquets signés, les métadonnées signées, les métadonnées de référentiel à durée de vie limitée, la protection contre les retours en arrière, la signature par seuil et la surveillance indépendante permettent chacune de verrouiller une porte différente.
Il existe un contre-argument : les petits fournisseurs ne peuvent pas mettre en place du jour au lendemain un niveau de sécurité des dépôts équivalent à celui de Debian. C'est vrai. Mais au minimum, les logiciels côté serveur qui s'installent avec des privilèges élevés devraient vérifier les signatures cryptographiques côté client avant l'installation. Compte tenu du niveau de risque, il est difficile de justifier une mesure moins stricte.
The broader cloud security lesson is familiar: infrastructure controls and application controls have to mature together. If you treat them separately, you get exactly this kind of gap, which is why the argument in Les services cloud et la sécurité évoluent de concert Cela s'applique parfaitement à ce cas-ci.
FAQ
Qu'est-ce qu'une attaque par détournement BGP ?
Une attaque de détournement BGP se produit lorsqu'un réseau annonce des routes IP qu'il n'est pas autorisé à émettre, ce qui conduit d'autres réseaux à acheminer le trafic par un chemin erroné. Les routes plus spécifiques, telles qu'une route /24 prenant le pas sur une route /16, sont souvent privilégiées par les règles de routage Internet par défaut.
Toutes les installations de Virtualizor ont-elles été compromises ?
Non. Virtualizor, Softaculous et BleepingComputer ont fait état de la diffusion de mises à jour malveillantes vers un petit nombre, voire une poignée, d’installations ayant vérifié la présence de mises à jour lors d’un détournement de routage. Le fournisseur a également indiqué qu’il ne pouvait pas établir de liste définitive des serveurs affectés, car les réponses malveillantes provenaient du système de l’attaquant.
Pourquoi un certificat TLS valide peut-il être dangereux dans ce cas précis ?
Le certificat peut être techniquement valide si l'attaquant contrôle le chemin de transmission lors de la validation du domaine. Dans ce cas, le protocole TLS peut chiffrer une connexion vers un serveur contrôlé par l'attaquant au lieu de bloquer la mise à jour malveillante.
Le RPKI permet-il d'empêcher ce type d'attaque ?
Le RPKI et la validation de l'origine des routes (ROA) peuvent limiter la propagation de routes erronées, mais ces mécanismes ne sont pas suffisants à eux seuls. Dans le cadre de cet incident, Ars Technica a rapporté que le chemin AS falsifié restait valide au regard du RPKI, car la ROA autorisait des longueurs de préfixe comprises entre /16 et /24.
Quel est le premier indicateur que les administrateurs de Virtualizor doivent vérifier ?
Virtualizor et BleepingComputer ont tous deux désigné /etc/systemd/system/java-jre-update.service comme un indicateur d'une éventuelle intrusion. Si vous le détectez, conservez les preuves et considérez l'hôte comme potentiellement compromis.
FR 
EN 
ES