Domaines placeholders malveillants : comment third-party[.]com compromet des milliers de projets

En septembre 2026, une découverte alarmante a secoué la communauté de la cybersécurité : le domaine third-party[.]com, pourtant utilisé depuis des années comme simple placeholder dans la documentation technique, a été détourné pour servir des attaques de type ClickFix. Selon Manifold Security, plus de 1 700 dépôts publics sur GitHub référencent ce domaine, y compris des projets d’IA et d’agents logiciels. L’ampleur du risque est considérable : tout développeur ou entreprise ayant utilisé ce domaine dans du code, une documentation ou un test expose ses utilisateurs à des prises de contrôle à distance.

Ce cas illustre parfaitement une menace émergente : les domaines placeholders non réservés (comme third-party[.]com, your-site[.]com, mycompany[.]com) peuvent être enregistrés par des acteurs malveillants et transformés en vecteurs d’infection. Dans cet article, nous détaillons le fonctionnement de l’attaque, les techniques d’ingénierie sociale employées, les implications pour les développeurs et les utilisateurs, ainsi que les mesures concrètes pour sécuriser vos projets.

L’affaire third-party[.]com : un placeholder devenu arme

Le domaine third-party[.]com était utilisé depuis des années comme exemple générique dans la documentation, au même titre que example.com. Comme l’explique Ax Sharma, responsable de la recherche chez Manifold Security : « third-party[.]com a été un placeholder générique dans la documentation pendant des années, le même rôle que joue example.com. Contrairement à example.com, third-party[.]com n’est pas réservé par l’IANA. N’importe qui pouvait l’enregistrer, et quelqu’un l’a fait. Chaque document, test et compétence qui l’avait codé en dur pointe désormais les lecteurs vers une infrastructure malveillante. »

L’analyse de la menace a montré que le domaine servait un contenu différent selon le système d’exploitation du visiteur :

• Pour les utilisateurs Windows : une fausse vérification Cloudflare s’affiche, accompagnée d’un message d’erreur invitant à copier et exécuter une commande via la boîte de dialogue Exécuter de Windows. La commande injectée télécharge et exécute une charge utile PowerShell distante.
• Pour les utilisateurs macOS : un écran indique que le site n’est pas compatible et exige un environnement Windows, empêchant l’exécution directe mais limitant les dégâts.

Cette approche - appelée ClickFix ou pastejacking - repose sur le détournement du presse-papiers pour coller automatiquement des commandes malveillantes dans le terminal ou la boîte de dialogue Exécuter. Le piège est redoutablement efficace car il exploite la confiance aveugle dans un nom de domaine familier.

ClickFix : la technique d’ingénierie sociale derrière l’attaque

ClickFix est une technique d’ingénierie sociale qui s’appuie sur l’urgence et la crédulité de l’utilisateur. Voici le scénario typique :

1. Un internaute clique sur un lien pointant vers un site compromis ou un domaine placeholder malveillant.
2. Le site affiche une alerte système fictive : « Votre connexion n’est pas sécurisée. Cliquez ici pour installer le correctif. »
3. En arrière-plan, du code JavaScript modifie le presse-papiers pour y placer une commande PowerShell malveillante.
4. L’utilisateur est invité à ouvrir la fenêtre Exécuter (touche Windows + R) et à coller (Ctrl+V) le contenu. La commande s’exécute alors avec les privilèges de l’utilisateur courant.

Ce procédé contourne les mécanismes de sécurité classiques (antivirus, pare-feu) car l’utilisateur exécute volontairement la commande. La technique a été documentée par plusieurs équipes de recherche, mais l’utilisation d’un domaine placeholder aussi répandu amplifie considérablement la menace.

« Vous pouvez analyser 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 sur ce qu’un agent Windows reçoit lorsqu’il suit le même lien. Une analyse de fichier ne peut pas voir ce qu’un site web décide d’envoyer. Le signe n’apparaît qu’au moment de la requête, depuis le client qui compte. » - Manifold Security

Impact sur les développeurs et les projets d’IA

Le danger ne se limite pas aux utilisateurs finaux. Les dépôts concernés incluent des projets d’IA, des skills d’agents, des docs MCP (Model Context Protocol), etc. Lorsque ces bibliothèques sont intégrées dans des applications, le domaine malveillant peut être appelé automatiquement par un agent - sans intervention humaine -, ouvrant la voie à des injections de prompt et à des comportements non prévus.

Prenons un exemple concret : un développeur français crée un agent de scraping qui utilise third-party[.]com comme endpoint de test. L’agent, déployé en production, tente de résoudre ce domaine et se retrouve à exécuter une commande malveillante. Non seulement la machine est compromise, mais l’attaquant peut ensuite pivoter vers le reste du réseau.

Selon les chercheurs, ces domaines placeholders non réservés sont squattables - n’importe qui peut les enregistrer pour quelques euros. Un acteur malveillant n’a qu’à surveiller les dépôts GitHub pour identifier les domaines les plus utilisés, puis les enregistrer et y héberger du contenu malveillant. C’est exactement ce qui s’est passé avec third-party[.]com.

Les 13 autres domaines placeholders non réservés identifiés

Suite à la découverte de third-party[.]com, Manifold Security a recherché d’autres domaines placeholders non réservés par l’IANA. 13 noms de domaine supplémentaires ont été identifiés, et au moins deux d’entre eux (yoursite[.]com et your-domain[.]com) distribuent déjà des contenus malveillants :

• your-domain[.]com : affiche un faux « centre de sécurité macOS » signalant quatre virus, puis propose un abonnement McAfee à 55 % de réduction (escroquerie).
• yoursite[.]com : diffuse un article frauduleux imitant la chaîne ZDF, promouvant un système d’investissement bidon.

Voici la liste complète des domaines dangereux signalés par Manifold Security. Tous passent les vérifications statiques (antivirus, analyse de fichiers), mais se révèlent malveillants lors d’une requête depuis le bon environnement :

« Les scarewares et les fraudes à l’investissement constituent une menace moindre que les malwares par presse-papiers, mais l’exposition qu’ils exploitent est bien plus large - et rien de tout cela n’est apparu dans les vérifications statiques que nous avons effectuées. » - Cody Nash, chercheur chez Manifold Security

Ces domaines sont présents dans des centaines de milliers de fichiers GitHub et dans de nombreux projets d’agents logiciels. Le risque pour les entreprises françaises est réel : toute application utilisant l’un de ces domaines comme placeholder peut être détournée.

Comment sécuriser vos projets et éviter ces pièges

Face à cette menace, plusieurs actions concrètes s’imposent. Nous les détaillons sous forme de liste actionnable.

1. Auditer les références à des placeholders non réservés

• Utilisez des outils de recherche de code (grep, GitHub search, scanners SAST) pour identifier les occurrences de third-party[.]com, your-domain[.]com, yoursite[.]com et autres domaines listés ci-dessus.
• Recherchez également des variantes non listées mais plausibles : mydomain[.]com, myapi[.]com, etc.
• Pour chaque occurrence, remplacez le domaine par un sous-domaine sous votre contrôle ou par un véritable placeholder réservé.

2. N’utiliser que des domaines réservés par l’IANA

Les seuls noms de domaine explicitement réservés à titre d’exemple par l’Internet Assigned Numbers Authority (IANA) sont :

• example.com
• example.org
• example.net

Ces domaines ne pourront jamais être enregistrés par un tiers. Tout autre domaine (même s’il semble inoffensif) est potentiellement squattable. Les rédacteurs de documentation, développeurs de tests et créateurs de skills doivent impérativement utiliser ces domaines réservés.

3. Traiter les placeholders comme des dépendances actives

Les placeholders ne sont pas que des chaînes de caractères neutres. Ils deviennent des pointeurs vivants vers de véritables ressources. Dès qu’un domaine placeholder est intégré dans un projet, il faut le considérer comme une dépendance externe et le surveiller régulièrement.

• Mettez en place une veille sur les domaines que vous utilisez (via VirusTotal, Safe Browsing, ou des services de threat intelligence).
• Si un domaine non réservé est repéré, remplacez-le immédiatement et relâchez une mise à jour de sécurité.

4. Former les équipes de développement

• Organisez une sensibilisation aux risques des placeholders. Expliquez la différence entre domaines réservés et non réservés.
• Incluez cette règle dans vos guides de style de documentation et dans vos standards de code.
• Utilisez des linters (ex. markdown-lint avec une règle personnalisée) pour détecter automatiquement les domaines suspects.

5. Mettre à jour les projets d’IA et d’agents

Les skills et MCP servers sont particulièrement vulnérables car ils exécutent du code en réponse à des requêtes. Vérifiez vos dépôts publics et privés ; si un agent fait appel à un domaine non réservé, il peut être victime d’injection de prompt.

• Scannez l’ensemble de votre base de code avec un script dédié.
• Pour les projets open source, soumettez des pull requests de correction.

6. Activer les restrictions réseau pour les agents

• Les agents exécutés dans des environnements conteneurisés doivent avoir des règles de pare-feu limitant les connexions sortantes aux seuls domaines de confiance.
• Utilisez des listes blanches (allowlists) plutôt que des listes noires, car de nouveaux domaines placeholders malveillants peuvent apparaître à tout moment.

Conclusion : une vigilance accrue sur les placeholders

L’affaire third-party[.]com n’est que la partie émergée de l’iceberg. Les 13 autres domaines identifiés montrent que la menace est systémique : tout placeholder non réservé peut être retourné contre ses utilisateurs. Alors que les projets d’IA et les agents logiciels se multiplient, la surface d’attaque ne cesse de croître.

Pour les professionnels de la cybersécurité en France, cette découverte rappelle quelques principes fondamentaux :

• Ne faites jamais confiance à un nom de domaine non réservé par l’IANA.
• Considérez que tout contenu provenant d’un domaine externe est potentiellement malveillant, même s’il s’agit d’une documentation anodine.
• Adoptez une approche zero trust vis-à-vis des placeholders : auditez, remplacez, surveillez.

En pratique, si vous utilisez encore your-app[.]com ou vendor[.]com dans vos fichiers de test, agissez dès aujourd’hui. Remplacez-les par example.com. Sinon, vous risquez, comme des milliers de projets, de servir involontairement de vecteur d’attaque ClickFix.

Les équipes de sécurité doivent également intégrer cette menace dans leur processus de gestion des actifs numériques. Les placeholders ne sont pas inoffensifs : ils sont devenus des cibles de choix pour les cybercriminels.

Pour approfondir, consultez les recommandations de l’ANSSI concernant la sécurisation des chaînes d’approvisionnement logicielle, ainsi que les bonnes pratiques du NIST sur l’utilisation de domaines réservés. La vigilance est le premier rempart face à ces attaques insidieuses qui exploitent notre propre confiance.