Cybersécurité

Un domaine de test courant dans les documents destinés aux développeurs se transforme en piège ClickFix pour les utilisateurs de Windows

Le domaine third-party.com, utilisé depuis des années comme adresse fictive dans des documents et exemples de code, a commencé à afficher une fausse page Cloudflare incitant les utilisateurs de Windows à exécuter des commandes PowerShell malveillantes. Aucun rapport confirmé ne fait état de la réussite de l’attaque, mais la présence du domaine dans des dépôts et projets publics en fait un risque potentiel pour le code copié tel quel.

2026-09-23
4 min de lecture
91 vues
certi.news Editorial Team
Un domaine de test courant dans les documents destinés aux développeurs se transforme en piège ClickFix pour les utilisateurs de Windows

Le domaine third-party.com, qui apparaît souvent dans les documents destinés aux développeurs et les exemples de code en tant que site externe fictif, est devenu une plateforme hébergeant une fausse page Cloudflare qui met en œuvre la méthode ClickFix pour cibler les utilisateurs de Windows. Manifold Security a découvert cet usage malveillant lors de l’examen de documents liés aux compétences en intelligence artificielle et aux serveurs MCP, puis BleepingComputer a confirmé le comportement de la page.

La page affiche un message de vérification intitulé « Performing security verification » et contient une case « Verify you are human ». Après un clic, la page copie une commande malveillante dans le presse-papiers de Windows et demande à l’utilisateur d’appuyer sur Windows+R, puis de coller la commande avec Ctrl+V et de l’exécuter. La commande reconstruit une adresse de charge utile à partir du domaine elxxvvx[.]xyz, télécharge un script PowerShell et l’exécute.

Comment fonctionne le piège ?

ClickFix repose sur la persuasion de la victime afin qu’elle exécute elle-même la commande, plutôt que de télécharger directement un fichier malveillant. Selon un rapport d’analyse antérieur daté du 2 mai 2026, le script tentait de télécharger une archive ZIP de 134 mégaoctets nommée update2.zip, de l’enregistrer localement sous le nom update26.zip, puis de la décompresser et d’exécuter un fichier nommé draw.io.exe. BleepingComputer n’a pas pu déterminer la charge utile finale, car l’archive n’était plus disponible.

Lors des tests, le domaine elxxvvx[.]xyz ne se résolvait plus vers un service actif, ce qui a interrompu la chaîne d’attaque à ce moment-là. Toutefois, la page distinguait les systèmes d’exploitation : les utilisateurs de Windows voyaient le parcours d’attaque, tandis que les utilisateurs de macOS et de Linux recevaient un message indiquant que le site nécessitait un appareil Windows. Ce ciblage sélectif peut dissimuler le comportement aux contrôles effectués dans des environnements Linux ou depuis des adresses de centres de données.

Pourquoi le choix de ce domaine est-il important ?

La gravité de l’incident tient au fait que third-party.com n’est pas un domaine réservé à la documentation comme example.com, example.net et example.org, mais un domaine enregistré dont le propriétaire peut contrôler le contenu. Il a néanmoins été utilisé par les spécifications du W3C, la documentation de Chromium et d’autres projets comme adresse fictive, et apparaît dans plus de 1 500 fichiers répartis sur plus de 1 700 dépôts, parmi lesquels des dépôts associés à des noms tels que Chromium, Sanity et Vercel.

Si des exemples contenant cette adresse sont copiés dans du code de test ou une application réelle, le navigateur ou l’outil automatisé peut se connecter au domaine réel au lieu de le considérer comme une valeur non opérationnelle, ce qui ouvre la voie à l’affichage de contenu malveillant. Cela ne signifie pas que les projets du W3C, de Chromium ou d’autres projets ont été compromis.

Que savons-nous et qu’est-ce qui n’a pas été établi ?

La source indique que le domaine est enregistré depuis 1996 et qu’aucun élément ne prouve qu’il a été réservé à l’origine dans un but malveillant. On ne sait pas non plus quand ni comment le contrôle du domaine a changé de mains. Au moment de la préparation du rapport, aucun rapport ne confirmait l’exécution effective de ClickFix sur les appareils de développeurs ou au sein des applications et sites qui renvoient vers le domaine. Toutefois, le maintien du site en ligne signifie que les attaquants pourraient ultérieurement le relier à un nouveau domaine hébergeant une charge utile.

La leçon pratique pour les développeurs et les équipes de sécurité est de ne pas considérer automatiquement chaque domaine de test comme sûr simplement parce qu’il apparaît dans des documents fiables. Il convient de remplacer les adresses enregistrables par des domaines réservés à la documentation, d’examiner les exemples copiés qui effectuent de véritables requêtes réseau et de sensibiliser les utilisateurs au fait que les pages de vérification légitimes ne demandent généralement pas d’ouvrir la fenêtre Exécuter et de coller manuellement des commandes PowerShell.

Source de l’actualité
c
Auteur

certi.news Editorial Team

Dans la même catégorie

À lire également

Voir toutes les actualités