Domaine placeholder third-party[.]com compromis : une menace silencieuse pour la chaîne de développement

Plus de 1 700 référentiels publics sur GitHub pointent encore vers le domaine third-party[.]com, un placeholder générique utilisé depuis des années dans la documentation technique. En septembre 2026, ce domaine a été enregistré par un acteur malveillant et sert désormais une attaque ClickFix aux visiteurs utilisant Windows, transformant une simple adresse d’exemple en vecteur d’infection massive. Pour les entreprises françaises qui s’appuient sur des bibliothèques open source, des agents d’IA ou des scripts de test, cette compromission illustre une faille de confiance profonde dans les pratiques de développement : l’utilisation de domaines non réservés comme espaces réservés.

Cette menace n’est pas anecdotique : elle touche aussi bien les intégrations CI/CD que les « skills » d’agents intelligents, et elle échappe aux contrôles statiques traditionnels. Décryptage d’une attaque qui remet en cause des années d’habitudes, et conseils pour ne pas devenir la prochaine victime.

Le piège ClickFix : quand un simple placeholder devient un cheval de Troie

Qu’est-ce que la technique ClickFix ?

Le ClickFix est une technique d’ingénierie sociale qui exploite la confiance de l’utilisateur face à des messages d’erreur ou des alertes de sécurité factices. Concrètement, une page web compromise ou malveillante affiche un faux vérificateur CAPTCHA, une notification « Cloudflare check » ou une alerte système invitant l’utilisateur à copier une commande dans le presse-papiers, puis à l’exécuter dans la boîte de dialogue Windows Exécuter (ou le terminal macOS).

L’attaque repose sur le clipboard hijacking (ou pastejacking) : le site injecte automatiquement un script malveillant dans le presse-papiers de la victime. Si l’utilisateur suit les instructions - souvent sous pression - il colle et exécute une commande qui télécharge et lance un payload PowerShell distant. En quelques secondes, l’attaquant prend le contrôle de la machine.

Le cas third-party[.]com : un déploiement ciblé

Selon les recherches publiées par Manifold Security, le domaine third-party[.]com a commencé à diffuser le leurre ClickFix à partir de juin 2026. Les utilisateurs Windows qui visitent le domaine voient apparaître une fausse vérification Cloudflare qui empoisonne leur presse-papiers. La commande à coller dans la boîte de dialogue Exécuter déclenche le téléchargement et l’exécution d’un script PowerShell.

« third-party[.]com est un espace réservé générique de documentation depuis des années, au même titre que example[.]com. Mais contrairement à example[.]com, ce domaine n’est pas réservé par l’IANA. N’importe qui pouvait l’enregistrer, et quelqu’un l’a fait. Chaque documentation, test ou compétence qui l’a codé en dur pointe désormais vers une infrastructure malveillante. » - Ax Sharma, Head of Research, Manifold Security.

Le site adapte son comportement à l’agent utilisateur : un visiteur sous macOS reçoit un message d’erreur : « macOS is not supported. This website requires a Windows PC to access. » Un leurre bien conçu pour ne cibler que les systèmes vulnérables. Au moment de la rédaction, le domaine est marqué comme malveillant sur VirusTotal et Google Safe Browsing.

Pourquoi third-party[.]com est un cas d’école de la faille de confiance

La différence cruciale entre domaines réservés et non réservés

L’IANA (Internet Assigned Numbers Authority) a réservé un ensemble de domaines de premier niveau et de seconds niveaux à usage d’exemple : example.com, example.org, example.net. Ces domaines ne peuvent pas être enregistrés par des tiers. À l’inverse, third-party[.]com n’apparaît dans aucune liste réservée. Pourtant, des générations de développeurs l’ont utilisé comme placeholder dans des documentations, des tests unitaires, des configurations MCP (Model Context Protocol) et même des agents d’IA.

« Un scan statique du fichier, une résolution DNS, tout peut paraître anodin. Mais le serveur peut décider de servir un contenu différent selon l’agent utilisateur, l’IP ou l’en-tête HTTP. Le tell n’apparaît qu’au moment de la requête émanant de la machine qui compte. » - Manifold Security.

Une analyse de surface ne suffit pas : un fichier peut sembler inoffensif, mais à l’exécution, le domaine résolu peut livrer un code malveillant.

Le nombre alarmant de références

Une recherche sur GitHub montre que le domaine third-party[.]com est référencé dans plus de 1 700 dépôts publics, dont des projets liés à des compétences d’agents IA et des serveurs MCP. Ce nombre ne tient pas compte des dépôts privés ni des codes embarqués dans des appareils IoT. La surface d’exposition est gigantesque.

Parmi les exemples concrets :

• Un fichier de documentation pour une API de chatbot indique https://third-party.com/api/v1/ comme endpoint de test.
• Un script de déploiement utilise le domaine comme adresse de callback dans une configuration CI/CD.
• Un « skill » d’agent IA (par exemple pour un assistant vocal) référence third-party[.]com comme source de données.

Dans chaque cas, l’intention était légitime. Mais aujourd’hui, toute action qui résout ce domaine expose l’utilisateur ou le système à une compromission potentielle.

Les autres domaines placeholder à risque identifiés par Manifold Security

La compromission de third-party[.]com n’est pas un cas isolé. Les chercheurs ont immédiatement cherché d’autres placeholders non réservés couramment utilisés dans la documentation. Ils en ont trouvé 13, dont deux déjà actifs avec des contenus malveillants.

Liste des domaines passant les contrôles statiques

« Les scarewares et les fraudes aux investissements sont une menace moins élevée que les malwares par presse-papiers, mais l’exposition qu’ils exploitent est bien plus large, et rien n’est apparu dans les contrôles statiques que nous avons menés. » - Cody Nash, chercheur en sécurité chez Manifold Security.

Le chercheur a détaillé que your-domain[.]com affiche sur macOS une fausse fenêtre « MacOS Security Center » annonçant quatre virus et proposant un abonnement McAfee à 55 % de réduction. Quant à yoursite[.]com, il redirige vers un faux article ZDF (chaîne de télévision allemande) faisant la promotion d’un système d’investissement frauduleux.

L’ampleur du problème

Ces deux domaines malveillants sont présents dans des centaines de milliers de fichiers GitHub et dans des centaines de compétences (skills) d’agents. La menace est exponentielle : un simple copier-coller d’un bout de code contenant your-domain[.]com peut compromettre tout un environnement de développement.

Implications pour les développeurs et les équipes SecOps

Une faille de supply chain silencieuse

L’utilisation de placeholders non réservés constitue une vulnérabilité de supply chain au niveau du code source. Contrairement à une dépendance compromise (ex. librairie npm), ici le vecteur est plus insidieux car il ne nécessite pas d’exécution de code : il suffit que le domaine soit résolu au moment de l’exécution. Les conséquences peuvent être graves :

• Infection d’un poste développeur via un script de déploiement.
• Compromission d’un pipeline CI/CD si une étape télécharge une ressource depuis un domaine malveillant.
• Vol de credentials si un agent IA effectue une requête HTTP vers le domaine et qu’une redirection malveillante intercepte les en-têtes d’authentification.

Prompt injection et comportements non désirés

Les agents d’IA, en particulier ceux qui exécutent des actions sur le Web, sont directement vulnérables. Un agent qui suit un lien pointant vers third-party[.]com peut recevoir des instructions malveillantes via le contenu de la page (ex. injection de prompts). Cette attaque ouvre la voie à des injections de prompt et à d’autres comportements non intentionnels, comme le souligne le rapport de Manifold.

Pourquoi les contrôles statiques échouent

La plupart des outils de sécurité analysent le code source et les dépendances déclarées. Or, une URL codée en dur comme http://third-party.com/ ne déclenchera aucun avertissement : le domaine n’est pas dans une liste noire, le fichier semble sûr. Mais le serveur, lorsqu’il reçoit la requête d’une machine Windows, répond avec le malware. Aucune analyse statique ne peut anticiper cette double réponse du serveur.

« 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 être complètement dans l’erreur quant à ce que l’agent d’un utilisateur Windows reçoit lorsqu’il suit le même lien. Un scan de fichier ne voit pas ce qu’un site web décide d’envoyer » - Manifold Security.

Mesures correctives et bonnes pratiques pour éviter ces pièges

Utiliser exclusivement des placeholders réservés

L’IANA maintient une liste de domaines réservés à l’usage d’exemple. En français comme en anglais, la recommandation est simple : n’utilisez que example.com, example.org, example.net (ou les variantes avec example.com/subpath). Aucun autre domaine générique ne doit être codé en dur comme placeholder.

Auditer votre base de code et votre documentation

1. Rechercher les placeholders non réservés : lancez une recherche regex sur l’ensemble du code source pour détecter les schémas suivants : yourdomain\.com, acme\.com, company\.com, myapp\.com, etc.
2. Remplacer par des exemples réservés : pour chaque occurrence, remplacez par https://example.com/. Si un chemin spécifique est nécessaire, utilisez https://example.com/path.
3. Vérifier les dépendances : si une bibliothèque tierce utilise un tel placeholder, signalez-le à l’éditeur ou appliquez un correctif en local via un fichier hosts ou un proxy.

Surveiller les enregistrements de domaines suspects

Les équipes de sécurité peuvent mettre en place une veille sur les nouveaux enregistrements de domaines ressemblant à des placeholders courants. Des outils comme Domaintools ou WhoisXML permettent de suivre les créations. Si votre organisation utilise des domaines internes comme mycompany[.]com en exemple, il faut les considérer comme squattables et les enregistrer immédiatement, ou mieux, utiliser un sous-domaine de votre domaine principal (exemple.monentreprise.com).

Durcir les environnements de développement et CI/CD

• Bloquer les requêtes sortantes vers des domaines inconnus depuis les environnements de build.
• Utiliser un fichier /etc/hosts pour rediriger les placeholder connus vers localhost ou un serveur de test interne.
• Former les développeurs à ne jamais copier-coller d’URL d’exemple sans vérifier leur légitimité.

Adopter des pratiques de secure coding

Lors de la rédaction de documentation ou de la création de scripts de test, privilégiez les adresses génériques de type httpbin.org (qui appartient à l’écosystème HTTP) ou utilisez des symbolic placeholders comme <API_ENDPOINT> que l’utilisateur devra remplacer. Évitez à tout prix les noms de domaine réels non contrôlés.

Conclusion : la vigilance est de mise

La compromission de third-party[.]com et des treize autres placeholders identifiés par Manifold Security est un signal d’alarme pour toute la profession. Ce n’est plus une simple curiosité technique : c’est une menace active qui exploite des années de pratiques négligentes. Les équipes de développement, les responsables sécurité et les architectes système doivent agir sans attendre.

La bonne nouvelle est que les correctifs sont simples à mettre en œuvre : remplacer les placeholders non réservés par example.com, auditer le code, sensibiliser les équipes. Mais cette attaque rappelle aussi que la sécurité ne s’arrête pas au code : elle s’étend à la chaîne de confiance des ressources externes, y compris celles qui semblent inoffensives.

Alors que l’écosystème open source et les agents d’IA continuent de croître, chaque développeur doit intégrer ce principe : un domaine placeholder non réservé est une bombe à retardement. Prenez le temps de vérifier vos référentiels, vos documentations et vos compétences d’IA. La prochaine fois qu’un collègue vous enverra un lien vers third-party[.]com, n’oubliez pas : ce n’est plus un exemple, c’est un piège.