Domaine placeholder compromis : comment third-party[.]com expose 1 700 projets et vos systèmes

Selon Manifold Security, le domaine « third-party[.]com », utilisé depuis des années comme placeholder générique dans la documentation technique, a été observé en train de servir un leurre ClickFix aux navigateurs Windows depuis juin 2026. Cette découverte, relayée par le chercheur Ax Sharma, met en lumière une faille de confiance massive : alors que les développeurs et les rédacteurs techniques utilisent ce domaine comme exemple inoffensif, il pointe désormais vers une infrastructure malveillante. Avec plus de 1 700 références publiques sur GitHub - dont des repos d’agents IA et de documentation MCP -, l’impact potentiel est considérable. Cet article décrypte le mécanisme de l’attaque, analyse les risques pour les organisations et fournit des mesures concrètes pour éviter de telles compromissions.

Pourquoi un simple placeholder comme third-party[.]com menace-t-il votre sécurité ?

La sécurité des domaines placeholder est rarement une priorité dans les cycles de développement. Pourtant, le cas de third-party[.]com démontre qu’un nom de domaine générique, non réservé par l’IANA, peut être enregistré par n’importe qui à tout moment. Contrairement à « example.com », qui est réservé par la RFC 2606, third-party[.]com n’est protégé par aucune norme. Résultat : chaque document, test ou compétence d’IA qui l’utilise comme exemple devient une porte d’entrée potentielle pour un attaquant.

« Every doc, test, and skill that hard-coded it now points readers at attacker infrastructure », a déclaré Ax Sharma, chef de la recherche chez Manifold Security. Cette déclaration illustre l’ampleur du problème : des milliers de projets, y compris ceux liés à l’intelligence artificielle et aux serveurs MCP, intègrent ce domaine de confiance sans se poser de questions.

Le piège ClickFix : un scénario d’attaque en plusieurs étapes

L’attaque observée sur third-party[.]com utilise la technique de ClickFix, une forme d’ingénierie sociale où une page web légitime (ou compromise) affiche une fausse alerte de sécurité invitant l’utilisateur à copier et exécuter une commande pour « corriger » le problème. Concrètement, le site exploite le détournement de presse-papiers (pastejacking) : le code malveillant est automatiquement placé dans le presse-papiers de la victime, qui est ensuite incitée à le coller dans la fenêtre d’exécution Windows (Win+R) ou le terminal macOS.

« Windows users visiting the page are shown a Cloudflare check that poisons the victim’s clipboard and instructs them to paste and run the command via the Windows Run dialog. » - Manifold Security

Une fois la commande exécutée, elle télécharge et exécute une charge utile PowerShell distante, compromettant ainsi le poste de l’utilisateur. La ruse est d’autant plus redoutable que le site affiche un contenu anodin pour les utilisateurs macOS ou Linux, leur évitant d’éveiller les soupçons. Seuls les visiteurs sous Windows voient le leurre, ce qui rend la détection par analyse statique quasi impossible.

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

Une recherche sur GitHub montre que le domaine third-party[.]com est référencé dans plus de 1 700 dépôts publics, incluant des projets liés à l’apprentissage automatique, des compétences d’agents IA et des documentations de serveurs MCP (Model Context Protocol). Ces références sont majoritairement des placeholders légitimes, mais elles deviennent désormais des vecteurs d’attaque potentiels.

|| Type de projet | Nombre estimé de références | Risque principal | |:—|:—|:—| | Documentations techniques | ~900 | Pointage vers une fausse infrastructure lors de la lecture | | Tests unitaires et d’intégration | ~500 | Exécution de code malveillant dans les pipelines CI/CD | | Compétences d’IA et agents MCP | ~300 | Injection de commandes lors de l’apprentissage ou de l’exécution |

Cette diversité illustre que le problème dépasse le cadre de la simple documentation : il touche également les processus automatisés. Selon Manifold Security, « a file scan cannot see what a website decides to send. The tell only appears at request time, from the caller that matters ». Autrement dit, les outils d’analyse statique de code ne peuvent pas détecter cette menace car le contenu malveillant n’est servi qu’à un sous-ensemble de visiteurs (ceux avec un agent utilisateur Windows).

Les enseignements pour les développeurs et les équipes DevSecOps

Cette affaire souligne une vulnérabilité systémique : la confiance implicite accordée aux noms de domaine non réservés. Les équipes doivent repenser leurs politiques de sécurisation des dépendances externes. Voici quelques points clés à retenir :

• Les placeholders ne sont pas des espaces sûrs : contrairement aux adresses réservées (example.com, example.org, example.net), les domaines comme mycompany.com, your-api.com ou third-party.com peuvent être enregistrés par des tiers.
• L’analyse statique ne suffit pas : un fichier peut sembler inoffensif si l’analyseur utilise un navigateur Linux ou macOS, alors que l’attaquant cible uniquement les utilisateurs Windows.
• L’impact s’étend à l’IA : les compétences d’agents qui référencent ces domaines pour des appels API ou des tests peuvent être victimes d’injections de prompt ou de redirections non souhaitées.

Les autres domaines placeholder non réservés identifiés

À la suite de la découverte de third-party[.]com, Manifold Security a identifié 13 autres domaines placeholder qui ne sont pas réservés par l’IANA et qui pourraient être enregistrés à des fins malveillantes. Deux d’entre eux, yoursite[.]com et your-domain[.]com, servent déjà des contenus frauduleux. Voici la liste complète :

1. your-domain[.]com
2. yourdomain[.]com
3. your-site[.]com
4. yoursite[.]com
5. your-app[.]com
6. yourapp[.]com
7. myapp[.]com
8. mysite[.]com
9. acme[.]com
10. company[.]com
11. mycompany[.]com
12. vendor[.]com
13. foo[.]com

Exemples concrets : scareware et escroqueries à l’investissement

Le chercheur Cody Nash a détaillé les observations sur macOS :

« On a macOS browser, your-domain[.]com showed a fake “MacOS Security Center” claiming four viruses and selling a counterfeit McAfee renewal at 55% off. On another macOS render, yoursite[.]com showed a counterfeit ZDF news article advertising an investment scheme. »

Ces deux domaines sont présents dans des centaines de milliers de fichiers GitHub et dans des centaines de compétences d’agents. Leur niveau de menace est différent : il s’agit de scareware et de fraude d’investissement plutôt que de malware direct, mais la surface d’exposition est bien plus large. Aucune vérification statique n’a pu détecter ces contenus, car ils ne s’activent que lors de la requête côté client.

Comment auditer et sécuriser vos documents et projets

Face à cette menace, une approche proactive est indispensable. Voici les mesures concrètes recommandées par Manifold Security et les bonnes pratiques du secteur (RGPD, ANSSI, ISO 27001).

1. Utiliser exclusivement des domaines réservés IANA

Les développeurs doivent systématiquement privilégier les adresses suivantes dans leurs documentations, tests et exemples :

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

Ces domaines sont réservés par la RFC 2606 et ne peuvent pas être enregistrés. Évitez tout nom qui pourrait être acheté, même s’il semble inoffensif comme myproject.com ou yourapi.com.

2. Mettre en place une analyse dynamique des dépendances

Les outils de CI/CD doivent être configurés pour signaler toute référence à un domaine non réservé dans le code source ou la documentation. Une solution possible est d’utiliser un script de prétraitement qui extrait les noms de domaine et les compare à la liste IANA. Par exemple :

# Script de vérification de domaines placeholder
#!/bin/bash
grep -roP "https?://([a-zA-Z0-9.-]+)" . | grep -v -E "example\.(com|org|net)" | cut -d: -f2- | sort -u | while read url; do
  echo "Vérifier le domaine non réservé : $url"
done

3. Former les équipes et documenter les risques

La sensibilisation à la sécurité des placeholders doit faire partie des formations DevSecOps. Expliquez aux développeurs et rédacteurs techniques pourquoi third-party.com est dangereux et comment utiliser correctement les domaines réservés.

4. Auditer les dépôts existants

Lancez une recherche systématique dans vos repos privés et publics pour détecter la présence de domaines non réservés. GitHub propose des fonctionnalités de recherche de code ; vous pouvez également utiliser des outils comme git grep ou des scanners SAST (Static Application Security Testing) avec des règles personnalisées.

5. Appliquer le principe de moindre confiance aux dépendances web

Toute ressource externe référencée dans la documentation ou les tests doit être traitée comme potentiellement hostile. Utilisez des sandbox ou des réseaux isolés pour les tests d’intégration, et ne présumez jamais de l’intégrité d’un site simplement parce qu’il a été inoffensif par le passé.

Conclusion : une vigilance indispensable pour les développeurs

L’affaire third-party[.]com est un signal d’alarme pour toute l’industrie du développement logiciel. La menace des domaines placeholder n’est pas un simple incident isolé : elle révèle une faille structurelle dans la manière dont nous concevons la documentation et les exemples de code. Avec plus de 1 700 repos exposés et 13 autres domaines identifiés comme potentiellement dangereux, les équipes techniques doivent agir sans attendre.

En pratique, chaque organisation devrait immédiatement auditer ses dépôts pour remplacer les mentions de third-party[.]com et des autres domaines non réservés par des adresses IANA sûres. Par ailleurs, l’intégration de contrôles automatisés dans les pipelines CI/CD permettra de prévenir de futures introductions. N’oublions pas que la sécurité ne s’arrête pas au code exécutable : la documentation, les tests et les configurations font partie intégrante de la surface d’attaque.

Nous vous invitons à partager ces bonnes pratiques avec vos équipes et à consulter les ressources de l’ANSSI et de l’OWASP pour approfondir la sécurisation des dépendances. En attendant, restez vigilants : un simple exemple dans un fichier markdown peut être la porte d’entrée vers une compromission plus large.