Domaine placeholder piégé : comment third-party[.]com est devenu un vecteur d’attaque ClickFix

Une menace silencieuse venue des placeholders : le cas third-party[.]com

En septembre 2026, un constat alarmant a secoué la communauté cybersécurité : le domaine générique third-party[.]com, utilisé depuis des années dans la documentation technique comme exemple inoffensif, a été observé en train de servir du contenu malveillant via la technique ClickFix. Selon les données de VirusTotal et Google Safe Browsing, ce domaine est désormais marqué comme malveillant et dangereux. Plus de 1 700 dépôts publics sur GitHub contiennent des références à ce domaine, exposant potentiellement des milliers de développeurs et d’utilisateurs à des attaques de pastejacking.

Ce scénario illustre un angle mort critique dans les pratiques de développement : l’utilisation de noms de domaine non réservés comme placeholders dans du code, de la documentation ou des agents d’IA. Contrairement à example.com, qui est réservé par l’IANA (Internet Assigned Numbers Authority), third-party[.]com pouvait être enregistré par n’importe qui. Et c’est exactement ce qu’un acteur malveillant a fait, transformant un simple espace réservé en une porte dérobée.

Dans cet article, nous analysons en détail cette attaque, son fonctionnement, son ampleur, et les leçons à en tirer pour sécuriser vos projets. Vous découvrirez pourquoi les vérifications statiques ne détectent pas ce type de menace et comment adopter des pratiques robustes pour éviter de futures compromissions.

ClickFix et pastejacking : le mécanisme de l’attaque

Qu’est-ce que ClickFix ?

ClickFix est une technique d’ingénierie sociale qui consiste à afficher un faux message d’erreur ou une fausse vérification de sécurité (CAPTCHA, avertissement de navigateur) pour inciter une victime à copier et exécuter une commande malveillante. L’attaque repose sur le clipboard hijacking (ou pastejacking) : le site malveillant injecte automatiquement un script dans le presse-papiers de l’utilisateur, en lui demandant de le coller dans la boîte de dialogue Windows Exécuter (Win+R) ou dans un terminal.

« ClickFix est une technique dans laquelle des sites web, légitimes ou compromis, affichent des messages d’erreur, des alertes de navigateur ou des invites de vérification CAPTCHA, trompant les utilisateurs pour qu’ils copient et exécutent des commandes cachées via la boîte de dialogue Exécuter de Windows ou le Terminal afin de « résoudre » le problème. » - Extrait du rapport de Manifold Security.

Le ciblage différencié : Windows vs macOS

L’une des caractéristiques les plus insidieuses de l’attaque third-party[.]com est sa capacité à servir un contenu différent selon le système d’exploitation du visiteur. Un utilisateur Windows se voit présenter une fausse vérification Cloudflare qui empoisonne son presse-papiers et lui demande de coller une commande dans Win+R. La commande est conçue pour télécharger et exécuter une charge utile PowerShell à distance.

En revanche, un visiteur sous macOS reçoit un message d’erreur anodin : « macOS is not supported. This website requires a Windows PC to access. Please try again from a Windows device. » Ce comportement permet à l’attaquant d’éviter les contrôles de sécurité automatisés qui s’appuient sur des machines virtuelles macOS ou Linux, et de ne cibler que les utilisateurs Windows, plus nombreux et plus vulnérables à ce type d’attaque.

« Un scan de fichier ne peut pas voir ce qu’un site web décide d’envoyer. L’indice n’apparaît qu’au moment de la requête, depuis l’appelant qui compte. » - Manifold Security.

Plus de 1 700 dépôts GitHub exposés : l’ampleur du problème

Le domaine third-party[.]com était présent dans plus de 1 700 dépôts publics sur GitHub au moment de la découverte. Ces dépôts incluent des documentations, des fichiers de configuration, des tests unitaires, mais aussi des compétences d’agents d’IA et des serveurs MCP (Model Context Protocol) qui utilisaient le domaine comme exemple de point d’accès. Les développeurs copient souvent ces extraits sans vérifier la validité du domaine.

Cette situation crée un vecteur d’attaque indirect : un agent d’IA qui référence ce domaine peut, lors de l’exécution, envoyer une requête à un serveur contrôlé par l’attaquant. Les conséquences peuvent aller de l’extraction de données à l’exécution de code malveillant, en passant par des attaques de prompt injection.

« Dans chacun de ces endroits, c’est exactement ce à quoi cela ressemble : un espace réservé, un exemple, un substitut, et une utilisation tout à fait raisonnable de la part des équipes concernées. C’est aussi, désormais, un pointeur vivant vers un serveur ClickFix. » - Ax Sharma, Head of Research chez Manifold Security.

Exemple concret de référence dans la documentation

# Configuration de l'API

Pour utiliser l'API, remplacez `https://third-party.com` par votre propre endpoint :

curl -X POST https://third-party.com/api/v1/data

Ce genre d’extrait, bien intentionné, devient une bombe à retardement si le domaine de démonstration est enregistré par un attaquant.

Les 13 autres domaines piégés : une liste qui s’allonge

Suite à l’alerte sur third-party[.]com, les chercheurs de Manifold Security ont identifié 13 autres domaines placeholder non réservés qui pourraient être utilisés de la même manière. Deux d’entre eux - yoursite[.]com et your-domain[.]com - servent déjà des scams et des scarewares aux visiteurs macOS, tandis qu’une page d’atterrissage banale s’affiche pour les autres utilisateurs.

« Sur un navigateur macOS, your-domain[.]com affichait un faux ‘MacOS Security Center’ prétendant avoir détecté quatre virus, et proposant un renouvellement contrefait de McAfee à -55 %. Sur un autre rendu macOS, yoursite[.]com montrait un faux article de ZDF faisant la promotion d’un système d’investissement frauduleux. » - Cody Nash, chercheur en sécurité.

Voici la liste complète des domaines identifiés, qui passent tous les contrôles statiques :

Ces deux domaines piégés sont référencés dans des centaines de milliers de fichiers GitHub et des centaines de compétences d’agents. « Les scarewares et les fraudes à l’investissement représentent une menace moindre que les malwares par presse-papiers, mais l’exposition qu’ils exploitent est bien plus vaste, et rien de tout cela n’est apparu dans les vérifications statiques que nous avons effectuées », a expliqué Nash.

Pourquoi les vérifications statiques ne suffisent pas

L’enseignement principal de cette affaire est que les méthodes traditionnelles d’analyse de sécurité (scan de code, analyse de dépendances, tests statiques) sont impuissantes face à ce type de menace. Un domaine placeholder comme third-party[.]com ne déclenche aucun alarme : il est utilisé depuis des années, présent dans des milliers de dépôts, et son contenu légitime passé ne laisse présager aucune malveillance.

Cependant, une fois le domaine enregistré par un attaquant, le serveur peut renvoyer du contenu différent selon l’user-agent, l’adresse IP, le système d’exploitation ou même l’heure de la requête. Une analyse statique du fichier ne révélera jamais ce comportement ; seule une analyse dynamique avec un environnement Windows réel pourrait le détecter.

« Vous pouvez scanner la compétence, lire le fichier, résoudre le domaine depuis votre boîte d’analyse, et conclure que tout va bien - et avoir complètement tort quant à ce que reçoit l’agent Windows d’un utilisateur lorsqu’il suit le même lien. » - Manifold Security.

Les limites des outils de sécurité traditionnels

• Scanners de vulnérabilités : ils vérifient les versions de bibliothèques, pas les noms de domaine non réservés.
• Analyse statique de code : elle peut détecter des chaînes suspectes comme curl, mais pas un domaine générique utilisé comme placeholder.
• Tests de régression : ils utilisent souvent des environnements de test distincts qui ne reproduisent pas le comportement réel du domaine.
• Plateformes de « bug bounty » : rares sont les programmes qui incluent les domaines placeholder dans leur périmètre.

Recommandations pour sécuriser documentation et code

Face à cette menace, les équipes de développement et de sécurité doivent adopter une approche proactive. Voici les mesures concrètes à mettre en œuvre dès aujourd’hui.

1. Utiliser exclusivement des domaines réservés par l’IANA

L’IANA a réservé plusieurs domaines à des fins de documentation et de test :

• example.com, example.org, example.net (RFC 2606)
• test.com (attention : non réservé officiellement, préférez example.com)
• example.edu, example.gov (réservés, mais moins courants)

Tout autre nom de domaine plausible - mycompany.com, yourapp.com, third-party.com - peut être enregistré par un tiers. Ne faites jamais confiance à un domaine que vous ne contrôlez pas, même s’il semble anodin.

2. Auditer vos dépôts et documentations

Effectuez une recherche systématique dans l’ensemble de votre code source, vos fichiers de configuration, vos README et vos documentations techniques pour détecter des domaines non réservés utilisés comme exemples. Utilisez des expressions régulières comme :

(?:your|my|our|third-party|company|app|site)[.]com

Si vous trouvez de telles références, remplacez-les immédiatement par example.com ou par un nom de domaine que vous contrôlez.

3. Mettre en place des vérifications automatisées dans le CI/CD

Intégrez une étape de linter ou de scanner personnalisé dans votre pipeline d’intégration continue pour bloquer toute nouvelle occurrence de domaines placeholder non réservés. Les outils open source comme grep ou ripgrep peuvent être utilisés, mais des solutions plus avancées (SAST) permettent de définir des règles spécifiques.

4. Former les développeurs aux risques des placeholders

Organisez des sessions de sensibilisation sur les bonnes pratiques de rédaction de documentation et de code d’exemple. Expliquez la différence entre les noms de domaine réservés par l’IANA et ceux qui sont « squattables ». Intégrez ce sujet dans votre Secure Development Lifecycle.

5. Surveiller les domaines que vous avez utilisés

Si vous avez déjà publié du code ou de la documentation avec un domaine non réservé (même comme placeholder), envisagez de l’enregistrer vous-même pour éviter qu’un attaquant ne le fasse. Cela peut être une solution temporaire, mais elle n’est pas scalable. La meilleure approche reste de supprimer les références.

6. Tester dynamiquement les accès externes

Pour les applications critiques, mettez en place des tests dynamiques qui simulent des requêtes réelles vers tout domaine externe référencé, en utilisant un environnement Windows avec un navigateur standard. Cela permet de détecter des comportements différentiés comme ceux observés avec third-party[.]com.

Conclusion : agir avant que la menace ne s’étende

L’affaire third-party[.]com n’est pas un incident isolé. C’est le signe avant-coureur d’une nouvelle classe de menaces où la confiance implicite accordée à des noms de domaine génériques se retourne contre les développeurs et les utilisateurs. Alors que les agents d’IA et l’automatisation se multiplient, le risque d’exécution involontaire de code malveillant via un placeholder piégé ne fera que croître.

Les chiffres parlent d’eux-mêmes : 1 700 dépôts GitHub exposés, 13 autres domaines prêts à être exploités, des centaines de milliers de fichiers contenant des références dangereuses. Les outils de sécurité traditionnels ne suffisent pas. C’est un changement de mentalité qui s’impose : traiter tout nom de domaine non réservé comme un vecteur d’attaque potentiel, et non comme un simple élément de documentation.

Adoptez dès maintenant les recommandations ci-dessus : auditez vos bases de code, formez vos équipes, et utilisez exclusivement des domaines réservés par l’IANA. La sécurité de vos applications - et celle de vos utilisateurs - en dépend.

Pour aller plus loin, suivez les publications de l’ANSSI et les rapports de Manifold Security sur les menaces liées à l’ingénierie sociale. Restez vigilants, car demain, un autre domaine placeholder pourrait être utilisé pour une attaque plus sophistiquée.