Tutoriels sur Joomla et la création de site

Un crâne en plein écran avec la mention « Hacked by AntonKill », ou pire, un site qui semble parfaitement normal mais affiche un faux contrôle « je ne suis pas un robot » à vos visiteurs. Depuis le 5 juillet 2026, des milliers de sites Joomla utilisant le framework Helix3 de JoomShaper sont touchés par une vague d'attaques automatisées. Le plus déroutant : un scan de fichiers classique, une restauration de sauvegarde des fichiers, un contrôle d'intégrité — tout revient « propre », alors que l'infection est toujours là. Nous avons nettoyé cette faille sur un site client cette semaine, jusqu'à découvrir sa variante la plus sophistiquée : un chargeur de code caché qui va chercher son payload final directement dans un smart contract sur la blockchain. Voici ce qu'il faut savoir, et comment agir.

Que s'est-il passé sur Helix3 ? Chronologie de la faille

La faille porte la référence CVE-2026-49049, avec un score de gravité CVSS de 7.5. Elle touche le plugin Helix3 - Ajax, distinct du plugin Système - Helix3 Framework, et relève d'un défaut de contrôle d'accès : le gestionnaire onAjaxHelix3, appelé via le dispatcher com_ajax de Joomla, exécutait des actions sensibles (écriture de fichier, suppression, import de réglages de template) sans jamais vérifier ni jeton de sécurité, ni identité de l'appelant. N'importe quel visiteur anonyme pouvait donc déclencher ces actions.

• 29 juin 2026 : JoomShaper publie Helix3 3.1.1, qui corrige la faille — mais sans changelog détaillé expliquant sa gravité réelle.
• 5 juillet 2026 : un botnet automatisé commence à exploiter en masse les sites restés sur une version antérieure, sous les signatures « Hacked by AntonKill » et « Hacked by trenggalek6etar ».
• Aujourd'hui : la version corrigée est la 3.1.2. Toute version de 1.0 à 3.1.0 reste vulnérable.

Ce scénario — un correctif discret suivi d'une exploitation de masse quelques jours plus tard — est devenu la norme sur l'écosystème Joomla en 2026 : nous l'avions déjà documenté avec la faille JCE CVE-2026-48907 et avec Helix Ultimate 2.2.7, corrigée la semaine suivante pour une famille de failles très proche.

Pourquoi votre site affiche-t-il un crâne, ou un faux CAPTCHA ?

Cette faille a deux visages, et le second est nettement plus dangereux que le premier.

La version visible : le défacement

La plus spectaculaire remplace toute la page par un fond noir, un crâne et le texte « HACKED BY ANTONKILL » ou « HACKED BY TRENGGALEK6ETAR », au-dessus de tout le reste grâce à un z-index extrême (2147483647, la valeur maximale possible). C'est brutal, mais au moins visible : vous savez immédiatement que quelque chose ne va pas.

La version silencieuse : le chargeur furtif

La variante que nous avons rencontrée sur un site client cette semaine est bien plus sournoise. Aucune page défigurée, aucun signe visible : à la place, un faux contrôle « je ne suis pas un robot » imitant reCAPTCHA s'affiche à certains visiteurs. Cliquer dessus ne vérifie rien — cela déclenche l'étape suivante de l'attaque, une technique connue sous le nom de ClickFix, qui pousse la victime à exécuter elle-même une commande malveillante copiée dans son presse-papiers.

En décodant le code JavaScript injecté sur ce site, nous avons découvert un mécanisme encore plus rare : le chargeur ne pointe vers aucun serveur pirate classique. Il interroge un nœud public de la blockchain Binance Smart Chain, lit une donnée stockée dans un smart contract, la décode, puis l'exécute directement dans le navigateur du visiteur. Cette technique, appelée EtherHiding, permet à l'attaquant de faire évoluer le payload final à volonté, sans jamais retoucher votre site — et sans qu'aucun hébergeur ni registrar ne puisse la faire retirer, puisqu'elle ne dépend d'aucune infrastructure web classique.

Pourquoi vos scans de fichiers classiques ne détectent rien

C'est le piège de cette faille, et la raison pour laquelle tant d'administrateurs restent bloqués : le code malveillant n'est écrit dans aucun fichier. Il est injecté directement dans la base de données Joomla, dans la colonne params de la table #__template_styles, à l'intérieur des champs de code personnalisé du style de template Helix3 : Custom JavaScript, Custom CSS, ou « Avant </head> ».

Or les outils de détection habituels — scanner de malware sur disque, comparaison d'intégrité de fichiers, restauration depuis une sauvegarde de fichiers propres — n'examinent que le système de fichiers. Aucun d'eux ne regarde le contenu d'une colonne de base de données. Résultat : le rapport de scan est vert, et le site reste infecté à chaque chargement de page.

Comment savoir si votre site Joomla est touché

Plusieurs signes doivent vous alerter : un crâne ou un message de défacement en...