Le domaine placeholder third-party.com diffuse désormais un leurre ClickFix aux machines Windows
Le 24 septembre 2026, Manifold Security a révélé que third-party.com, un domaine de documentation utilisé comme exemple depuis des années, a été enregistré par un tiers et sert maintenant un leurre ClickFix aux navigateurs Windows. Auditez vos dépôts et ne laissez plus qu’un domaine non réservé fasse office d’exemple.
Juin 2026. Le domaine third-party.com commence à servir un leurre ClickFix aux navigateurs Windows, tout en affichant une page anodine aux autres visiteurs. 24 septembre 2026. Manifold Security documente le détournement dans un rapport signé Ax Sharma et Cody Nash. 24 septembre 2026. VirusTotal et Google Safe Browsing marquent le domaine comme malveillant. Pourquoi c’est important : un placeholder de documentation est une promesse que personne ne décrochera jamais. Le DNS ne tient pas cette promesse.
Un exemple qui répond, pour de vrai
third-party.com a joué pendant des années le rôle que joue example.com dans les exemples de code : un nom de domaine qu’on écrit sans y penser, parce qu’on est certain qu’il ne mène nulle part. La différence entre les deux est pourtant capitale. example.com est réservé par l’IANA : personne ne peut l’enregistrer, par construction. third-party.com ne l’est pas. N’importe qui pouvait l’acheter, et quelqu’un l’a fait.
La conséquence est mécanique. Chaque documentation, chaque test, chaque skill d’agent IA qui a codé en dur ce domaine pointe désormais, littéralement, vers une infrastructure d’attaque. Ax Sharma, responsable de la recherche chez Manifold Security, résume la bascule : « third-party.com a été un placeholder générique pendant des années, le même rôle qu’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 doc, chaque test, chaque skill qui l’a codé en dur renvoie maintenant ses lecteurs vers une infrastructure d’attaque. »
Ce que voit la victime Windows
Le piège suit le mode opératoire ClickFix, devenu la technique de phishing la plus répandue de l’année. La page affiche un faux contrôle de sécurité Cloudflare qui prétend vérifier le navigateur, puis empoisonne le presse-papiers de la victime et lui ordonne d’ouvrir la boîte de dialogue Exécuter de Windows et d’y coller une commande. La commande collée télécharge et exécute une charge PowerShell distante.
La ruse est ciblée. Un visiteur macOS voit un message d’erreur : « macOS n’est pas pris en charge. Ce site requiert un PC Windows. » L’opérateur du domaine filtre donc les victimes selon l’en-tête User-Agent : la cible est la machine Windows, le macOS reçoit un leurre bénin pour ne pas éveiller les soupçons ni les signalements.
L’astuce du presse-papiers porte un nom : pastejacking. La page remplace silencieusement le contenu du presse-papiers par un script malveillant, si bien que la victime croit coller une vérification anodine alors qu’elle colle un ordre. C’est un détournement de confiance : l’utilisateur exécute lui-même la charge, en dehors de toute faille logicielle. Aucun antivirus ne peut intercepter une commande que la victime s’inflige volontairement.
Un placeholder n’est pas un exemple
Le vrai sujet n’est pas le leurre, mais ce qui l’a rendu possible : la confusion entre « domaine d’exemple » et « domaine réservé ». Les développeurs ont pris l’habitude d’utiliser des domaines plausibles — yourcompany.com, myapp.com, vendor.com — pour illustrer une adresse dans une documentation. Ces domaines ressemblent à des exemples, mais ils sont enregistrables, donc squattables.
Manifold Security a recensé 1 700 dépôts publics qui référencent third-party.com, y compris des skills d’agents IA et des documentations de serveurs MCP qui citent le domaine comme point de terminaison d’exemple. La recherche a ensuite élargi le filet : treize autres domaines placeholder non réservés ont été identifiés, dont yoursite.com et your-domain.com qui servent déjà des arnaques aux visiteurs macOS — un faux « MacOS Security Center » qui annonce quatre virus et vend un renouvellement McAfee contrefait à −55 %, et un faux article de ZDF qui pousse un placement financier.
Le détail qui tue : ces domaines passent tous les contrôles statiques. Un scanner de fichiers, un analyseur de dépôt, une revue de code ne voient qu’une chaîne de caractères inoffensive. « Vous pouvez scanner le skill, lire le fichier, résoudre le domaine depuis votre poste d’analyse et conclure que tout va bien, tout en vous trompant complètement sur ce que l’agent d’un utilisateur Windows reçoit quand il suit le même lien », avertit Manifold Security. Le contenu malveillant n’existe qu’au moment de la requête, et seulement pour l’appelant qui compte. Un scan de fichier ne peut pas voir ce qu’un site décide d’envoyer.
Les agents IA suivent les liens, eux aussi
Le détournement frappe d’autant plus fort qu’il touche la couche des agents IA. Les skills et les documentations de serveurs MCP citent des domaines d’exemple comme point de terminaison, et un agent qui exécute une tâche peut être amené à résoudre ce domaine pour de vrai. Manifold Security insiste : un scan de fichier conclut que tout va bien, mais ne peut pas voir ce qu’un site décide d’envoyer au moment de la requête. Le contenu malveillant n’existe que pour l’appelant qui compte.
La conséquence dépasse le simple phishing. Une documentation qui pointe vers un domaine squatté devient un vecteur de prompt injection : un agent qui lit un exemple d’endpoint et le suit peut recevoir en retour des instructions destinées à le détourner, et pas seulement à livrer une charge. La frontière entre « exemple inoffensif » et « infrastructure d’attaque » s’est déplacée vers le DNS, une couche que presque personne ne surveille au quotidien.
Le même piège, en plus large
Manifold Security a identifié treize domaines placeholder non réservés en plus de third-party.com, et deux d’entre eux sont déjà actifs. yoursite.com affiche un faux « MacOS Security Center » qui annonce quatre virus et vend un renouvellement McAfee contrefait à −55 %, tandis que your-domain.com sert une fausse actualité de la chaîne ZDF qui pousse un placement financier. La liste complète — yourdomain.com, your-site.com, yourapp.com, myapp.com, acme.com, company.com, vendor.com, foo.com — passe tous les contrôles statiques.
Le phénomène n’est pas isolé. Un domaine CDN abandonné a récemment été réenregistré, et des milliers de sites continuent de l’appeler sans le savoir. À chaque fois, le scénario est le même : un nom de domaine qu’on croyait mort redevient vivant entre de mauvaises mains, et le code qui le référençait se transforme en porte d’entrée. C’est la définition même d’un problème de supply chain au niveau du DNS.
Verdict
Si vous maintenez de la documentation, des exemples de code, des skills ou des tests, remplacez tout domaine placeholder par un domaine réservé — example.com, example.org, example.net. Ce sont les seuls qui ne peuvent pas être enregistrés, et donc les seuls qui ne peuvent pas devenir un point d’entrée. Si vous avez déjà codé en dur un domaine plausible, auditez vos dépôts dès maintenant : un grep -R "your.*\.com" sur vos README et vos fichiers de configuration est un début, puis traitez tout domaine non réservé comme squattable par construction. Si vous gérez un parc Windows, le risque est indirect mais réel : un utilisateur qui suit un lien de documentation depuis un poste non isolé peut coller une commande — rappelez que la boîte Exécuter n’a jamais rien à exécuter de collé. Le correctif n’est pas un correctif, c’est une convention : un exemple doit être réservé, sinon il devient un point d’entrée.