Un hijack BGP valide RPKI détourne les mises à jour de Softaculous vers un malware

28 août 2026, 20 h 57 UTC. Un préfixe inédit, 162.55.80.0/24, entre dans la table de routage mondiale avec une origine forgée AS24940 — celle de Hetzner. 30 août 2026. Le préfixe est retiré après environ 33 heures de détournement intermittent. 22 septembre 2026. Doug Madory (Kentik/Infoblox) publie dans l’APNIC Blog l’analyse complète de ce qui est devenu la distribution d’une mise à jour Virtualizor malveillante via un certificat TLS frauduleux. Pourquoi c’est important : l’attaque était valide RPKI, ce qui casse l’idée reçue selon laquelle la validation d’origine suffit à arrêter un adversaire déterminé.

Le contournement de RPKI, en trois ingrédients

L’attaque repose sur une faille de conception bien connue, exploitée ici avec soin. L’attaquant a annoncé 162.55.80.0/24, un sous-préfixe plus spécifique du 162.55.0.0/16 annoncé légitimement par Hetzner (AS24940). Le chemin annoncé se terminait par l’ASN de Hetzner :

… 6204 62390 24940

Ce chemin est un forgery d’origine : l’attaquant a ajouté 24940 à droite, faisant croire que Hetzner est l’origine. La route est probablement partie de NexonHost (AS62390), par compromission ou par un client abusant de failles de sécurité. Or cette route était valide RPKI, pour deux raisons : la ROA de Hetzner exigeait l’origine AS24940, et elle autorisait des préfixes de longueur comprise entre /16 et /24. Comme le préfixe /24 n’entrait en concurrence avec aucune route existante, il a été préféré au /16 légitime par la règle du longest prefix match : le trafic destiné à cette plage était donc redirigé vers l’attaquant.

Le préfixe a « pulsé » plusieurs fois : apparu à 20 h 57 UTC le 28 août, il s’est interrompu quand Hetzner a commencé à l’annoncer à 8 h 44 UTC le 29 août, est revenu à 19 h 55 UTC, puis a été retiré définitivement vers 5 h 45 UTC le 30 août.

Le certificat TLS, pièce manquante du puzzle

Le hijack seul ne suffisait pas. Pour que les clients acceptent la mise à jour, l’attaquant devait servir du contenu chiffré sous un certificat TLS valide. Le mécanisme est le même que celui de l’attaque contre KLAYswap en 2022, documentée par Henry Birge-Lee et ses collègues de Princeton : un hijack BGP sert d’abord à intercepter les requêtes de validation de domaine d’une autorité de certification, pour obtenir un certificat légitime.

Let’s Encrypt a répondu à ce risque avec la MPIC (Multi-Perspective Issuance Corroboration) : la validation du contrôle de domaine est effectuée depuis plusieurs points de vue géographiquement et topologiquement distincts, et un quorum doit s’accorder avant l’émission. Mais comme la route détournée était un sous-préfixe non contesté, sa propagation mondiale a produit un quorum entièrement contrôlé par l’attaquant. La MPIC, conçue pour détecter un hijack localisé, a été neutralisée par un hijack global.

Ce que ça a coûté, et pourquoi c’est reproductible

Softaculous a confirmé qu’un « certificat TLS techniquement valide », combiné au hijack, a permis de livrer une mise à jour Virtualizor malveillante à « un petit nombre d’installations ». L’entreprise a invité ses clients à réinitialiser leurs identifiants et à inspecter leurs serveurs. Ce n’est pas un incident isolé : la même technique avait visé Celer Bridge en 2022, et l’auteur de l’analyse rappelle qu’AWS utilisait alors des ROA très permissives.

La leçon technique est nette. La RPKI ROV (Route Origin Validation) réduit bien les erreurs de routage et les fuites accidentelles, mais elle n’est pas conçue pour bloquer un adversaire qui forge son chemin AS. Le vrai problème, ici, ce sont les ROA trop larges : le champ maxLength laissé à /24 alors que seul le /16 est routé crée un espace de 9 bits dans lequel un sous-préfixe malveillant peut circuler. Le RFC 9319 recommande d’ailleurs d’éviter maxLength et de laisser le champ vide — ce qui équivaut à un préfixe exact.

La réparation de Hetzner, et ce qu’elle révèle

Après la publication de l’analyse, Hetzner a corrigé la ROA de 162.55.0.0/16 en ramenant son maxLength à /16, supprimant ainsi la possibilité d’un sous-préfixe hijack identique à l’avenir. L’opérateur a fait de même pour 213.133.96.0/19 et 213.239.192.0/18, qui autorisaient encore des sous-préfixes jusqu’au /24.

Mais la correction reste partielle, et c’est le point le plus instructif. Doug Madory relève que 50 des ROA d’AS24940 présentent encore le même motif après le correctif : un bloc routé en /16 dont la ROA autorise jusqu’au /24, un écart de 9 bits prêt à être exploité. Une seule organisation, parmi les plus structurées du secteur, laisse donc encore des dizaines de brèches du même type ouvertes. Hetzner a par ailleurs ajouté un enregistrement ASPA listant ses fournisseurs autorisés, ce qui permet aux réseaux qui le vérifient de rejeter instantanément un chemin dont l’amont est inattendu — ici AS62390.

Ce cas illustre la hiérarchie des défenses. La ROV réduit les erreurs, les ROA stricts retirent l’espace où un sous-préfixe malveillant peut circuler, l’ASPA verrouille l’amont autorisé, et la surveillance BGP reste le filet qui détecte ce que les trois premières laissent passer. Aucune brique ne suffit seule : c’est leur combinaison qui réduit la fenêtre au point où la MPIC retrouve son efficacité.

Ce qu’il faut faire

La réponse tient en quatre mesures, dont trois sont gratuites et immédiates.

• 1. Serrer les ROA. Publiez des ROA dont le maxLength correspond exactement au préfixe routé, ou laissez le champ vide. L’écart maxLength est l’angle d’attaque exact exploité ici.
• 2. Rejeter les routes invalides. Déployez la RPKI ROV et jetez les routes INVALID. Elle n’aurait pas suffi seule, mais elle réduit la propagation d’un hijack et protège les incidents accidentels.
• 3. Déployer ASPA. Hetzner a ajouté un enregistrement ASPA listant ses fournisseurs autorisés. Les réseaux qui le vérifient rejettent instantanément un chemin dont l’amont n’est pas dans la liste — ici AS62390.
• 4. Surveiller ses préfixes. Une alerte BGP aurait dû se déclencher quand un /24 inédit de Hetzner est apparu transitant exclusivement par NexonHost. La surveillance de l’origine et de l’amont de vos préfixes est le filet de sécurité qui reste quand tout le reste échoue.

Verdict

Si vous annoncez de l’espace d’adressage sur Internet, commencez par corriger vos ROA : un maxLength trop large est une invitation ouverte à un sous-préfixe hijack, et c’est précisément ce qui a rendu cette attaque possible. Si vous opérez un service dont les mises à jour passent par HTTPS, ne tenez pas le TLS pour acquis : un certificat « valide » ne garantit rien si le routage qui l’a émis était détourné — la MPIC ne protège que contre un hijack localisé. Si vous dépendez de RPKI comme unique garde-fou, cet incident est le contre-exemple : forgez l’origine, et la route devient valide. La résilience passe par la combinaison ROA stricts + ROV + ASPA + surveillance BGP, pas par une seule brique.

Références

• APNIC Blog — Latest BGP hijack targets hosting software vendor (22 septembre 2026)
• Kentik — Latest BGP Hijack Targets Hosting Software Vendor
• The Register — 33-hour BGP hijack of Softaculous traffic prompts security scramble (1er septembre 2026)
• MANRS — Latest BGP Hijack Targets Hosting Software Vendor
• Virtualizor — Security Incident: BGP Hijacking (mise à jour)
• Princeton CITP — Attackers exploit fundamental flaw in the web’s security to steal $2 million (2022)
• RFC 9319 — The Use of MaxLength in the Resource Public Key Infrastructure