Domaine de documentation détourné : la menace ClickFix via third-party[.]com

En 2026, une découverte a secoué la communauté de la cybersécurité : le domaine « third-party[.]com », utilisé depuis des années comme simple espace réservé dans la documentation technique, a été enregistré par un acteur malveillant et sert désormais du contenu nuisible via la technique ClickFix. Selon Manifold Security, ce domaine était référencé dans plus de 1 700 dépôts publics sur GitHub, y compris au sein de compétences d’agents d’IA et de documentation de serveurs MCP. Pire encore, treize autres domaines placeholder non réservés par l’IANA - comme yoursite[.]com ou myapp[.]com - ont déjà été identifiés, dont deux diffusent déjà des escroqueries et du scareware. Cette attaque illustre un angle mort majeur dans les chaînes d’approvisionnement logicielles modernes, où un simple signe de ponctuation de code peut devenir un maillon faible exploité. Nous vous proposons une analyse complète de cette menace, de son fonctionnement et des mesures concrètes pour protéger vos développements.

Qu’est-ce que la technique ClickFix ?

La technique ClickFix, également appelée pastejacking dans certaines variantes, est une forme d’ingénierie sociale qui exploite le réflexe des utilisateurs à suivre des instructions visant à résoudre un pseudo-problème. Concrètement, lorsqu’un internaute visite une page compromise ou contrôlée par un attaquant, celle-ci affiche une alerte de sécurité fictive - par exemple un message « Cloudflare check » ou un faux « CAPTCHA ». L’alerte invite la victime à copier une commande dans le presse-papiers, puis à l’exécuter via la boîte de dialogue Exécuter (Windows) ou le Terminal (macOS).

« Les pages web utilisant ClickFix reposent souvent sur un détournement du presse-papiers pour injecter automatiquement un script malveillant dans le terminal de la victime. » - Rapport Manifold Security, septembre 2026.

L’utilisateur, pensant résoudre un problème légitime, colle et exécute la commande. Celle-ci établit alors une connexion avec un serveur distant pour télécharger et exécuter une charge utile PowerShell. Un utilisateur Windows visitant third-party[.]com se voit ainsi présenter une vérification Cloudflare factice, tandis qu’un visiteur macOS reçoit le message : « macOS is not supported. This website requires a Windows PC to access. » - une indication claire que la cible visée est le système d’exploitation de Microsoft.

Cette technique n’est pas nouvelle, mais sa combinaison avec des domaines de confiance (placeholders historiques) marque une évolution inquiétante. En 2025, le CERT-FR et l’ANSSI avaient déjà alerté sur les risques liés à l’emploi de noms de domaine non réservés dans la documentation technique. Aujourd’hui, ces mises en garde trouvent une illustration concrète.

Le détournement de third-party[.]com : un cas d’école

Jusqu’en 2026, le domaine third-party[.]com figurait dans d’innombrables exemples de code, tutoriels et spécifications techniques - exactement comme example.com l’est pour les adresses mail. Mais contrairement à example.com, third-party[.]com n’est pas réservé par l’IANA (Internet Assigned Numbers Authority). N’importe qui pouvait l’enregistrer. Et quelqu’un l’a fait.

D’après Ax Sharma, responsable de la recherche chez Manifold Security :

« third-party[.]com a été un espace réservé de documentation générique pendant des années, au même titre qu’example.com. Toutefois, 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 d’IA qui l’avait codé en dur pointe désormais les lecteurs vers une infrastructure malveillante. »

Concrètement, un développeur qui consulte la documentation d’une bibliothèque contenant third-party[.]com comme endpoint d’exemple peut (s’il suit le lien) être redirigé vers le site compromis. Mais ce qui est plus grave, c’est que les agents d’IA - ces programmes conçus pour effectuer des tâches de façon autonome - peuvent également consulter ces documents et, le cas échéant, exécuter des actions en se basant sur des exemples compromis. Cela ouvre la voie à des injections de prompt (prompt injection) et à des comportements non prévus par les développeurs.

Dans la pratique, l’attaque fonctionne en deux temps :

1. Phase d’amorçage : un utilisateur (ou un agent) consulte un document contenant third-party[.]com comme exemple valide.
2. Phase d’exécution : le document est suivi, le serveur malveillant détecte le type de client (Windows ou autre) et sert soit un leurre ClickFix, soit un contenu inoffensif (pour les autres systèmes).

Ce ciblage différencié permet de contourner les analyses statiques. Les outils de sécurité qui scannent le fichier ou la page depuis un serveur Linux ne déclenchent pas la charge malveillante. Seule une requête depuis un navigateur Windows révèle le piège.

L’impact sur les développeurs et la chaîne d’approvisionnement logicielle

Les répercussions de cette découverte dépassent le simple incident de sécurité. Plus de 1 700 références à third-party[.]com ont été recensées sur GitHub, dans des projets allant de simples fichiers de configuration à des compétences d’agents d’intelligence artificielle complexes. Ces projets incluent notamment des « skills » pour assistants IA, qui peuvent interpréter et exécuter des commandes en se basant sur des endpoints documentés.

Pire encore, les deux domaines yoursite[.]com et your-domain[.]com - présents dans des centaines de milliers de fichiers GitHub - servent aujourd’hui respectivement un scareware (fausse alerte Mac) et une escroquerie d’investissement déguisée en article de presse. Selon le chercheur Cody Nash :

« Sur un navigateur macOS, your-domain[.]com affichait un faux “MacOS Security Center” annonçant quatre virus et proposant un abonnement McAfee factice avec 55 % de réduction. Sur un autre rendu, yoursite[.]com présentait un faux article de la ZDF vantant un système d’investissement frauduleux. »

Ces attaques exploitent une faille de confiance dans la chaîne d’approvisionnement : un développeur qui inclut un exemple de code dans un tutoriel ne s’attend pas à ce que le domaine cité devienne un jour malveillant. Pourtant, aucun mécanisme ne garantit qu’un domaine non réservé ne sera pas enregistré ultérieurement par un tiers.

Les enseignements pour les équipes DevOps

• Les vérifications statiques sont insuffisantes : comme le souligne Manifold Security, un scan de fichier peut conclure qu’un domaine est inoffensif alors que celui-ci sert du contenu malveillant uniquement sous certaines conditions (système d’exploitation, agent utilisateur).
• Les placeholders privés (myapp[.]com, yourcompany[.]com) sont aussi vulnérables : ils peuvent être enregistrés par un concurrent ou un attaquant.
• Les agents d’IA amplifient le risque : un agent qui suit une documentation compromet non seulement sa propre exécution, mais peut aussi contaminer d’autres systèmes par l’écriture de nouveaux documents.

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

Manifold Security a publié une liste de treize domaines qui, bien que non réservés par l’IANA, sont couramment utilisés dans la documentation. Deux d’entre eux (marqués d’un * ci-dessous) étaient déjà actifs pour du scareware ou des escroqueries au moment de la publication.

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

Attention : cette liste n’est pas exhaustive. Tout domaine non réservé qui semble plausible peut être squatté. Nous vous recommandons de ne jamais utiliser de nom de domaine qui n’est pas soit réservé par l’IANA, soit sous votre contrôle direct.

Comment se prémunir de cette menace ?

La protection contre ce type de détournement repose sur une combinaison de bonnes pratiques de développement, d’audits de code et de sensibilisation. Voici une marche à suivre concrète.

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

La recommandation de l’ANSSI et du CERT-FR est claire : dans la documentation, les tests et les exemples, préférez toujours les domaines réservés :

• example.com / example.org / example.net
• test.example.com
• Les sous-domaines de example.com

Ces domaines ne peuvent pas être enregistrés par un tiers, car leur réservation est garantie par l’IANA (RFC 2606).

2. Mettre en place une veille active

Pour les projets existants, effectuez une recherche automatisée dans vos dépôts Git des motifs suivants : *.com, *.org, *.net qui ne sont pas dans une liste blanche de domaines approuvés. Des outils comme truffleHog, Gitleaks ou des scripts grep peuvent vous aider à identifier les domaines suspects.

grep -rnE 'https?://[a-zA-Z0-9.-]+\.[a-zA-Z]{2,}' ./docs | grep -v 'example\.com' | grep -v 'test\.example\.com'

Ce type de script est un premier filtre, mais il ne remplacera jamais une vérification dynamique.

3. Vérifier dynamiquement les domaines tiers

Avant d’inclure un domaine d’exemple dans un document, vérifiez son statut d’enregistrement via WHOIS ou un service comme DomainTools. Assurez-vous qu’il est réservé par l’IANA ou qu’il appartient à votre organisation.

4. Durcir les agents d’IA

Si vos équipes développent des compétences pour assistants IA (GPT, Claude, etc.), intégrez une couche de validation des endpoints : interdisez formellement l’exécution de commandes qui utilisent des domaines inconnus. Utilisez un fichier de configuration allowed_domains.json mis à jour régulièrement.

5. Sensibiliser les développeurs

Organisez une session de sensibilisation sur les risques des placeholders non réservés. Présentez le cas third-party[.]com comme démonstration. Insistez sur le fait que la confiance implicite en un nom de domaine est un angle mort dangereux, surtout dans un contexte d’ingénierie sociale via ClickFix.

6. Mettre à jour les projets existants

Lancez une campagne de correction dans l’ensemble de vos dépôts : remplacez tout domaine non réservé par example.com ou, si un endpoint réel est nécessaire, par un domaine que vous possédez et que vous pouvez surveiller. Attention : le simple remplacement peut casser des tests automatisés ; prévoyez une période de migration avec des redirections temporaires.

Conclusion : repenser la confiance dans les placeholders

L’affaire third-party[.]com n’est pas un incident isolé. Elle révèle une faiblesse structurelle dans la manière dont nous concevons la documentation et le code. Un domaine qui semble inoffensif aujourd’hui peut devenir demain le maillon faible d’une chaîne d’approvisionnement entière. Les attaques ClickFix, amplifiées par ce vecteur, montrent que les méthodes d’ingénierie sociale restent redoutables lorsqu’elles s’appuient sur des ressources légitimes aux yeux des développeurs.

En tant que professionnels de la cybersécurité, nous devons repenser nos pratiques de vérification : une analyse statique ne suffit plus, car un domaine peut se comporter différemment selon le client qui l’interroge. L’utilisation de placeholders réservés (IANA) n’est pas une option, c’est une obligation de base. De plus, le phénomène met en lumière la nécessité de surveiller activement les références à des domaines externes dans les dépôts de code, surtout si ceux-ci sont utilisés par des agents autonomes.

Pour aller plus loin, nous vous conseillons de consulter les référentiels suivants :

• ANSSI - Guide de sécurisation des chaînes logicielles (2025)
• ISO 27001 - Annexe A.8.8 (Management de la sécurité des actifs informationnels)
• OWASP - Supply Chain Security (projet en cours)

Enfin, n’oubliez pas que la menace évolue. Manifold Security a déjà identifié 13 domaines supplémentaires ; d’autres suivront. Adoptez une posture de défense en profondeur et intégrez la vérification dynamique des dépendances dans votre pipeline CI/CD.

Pour une prochaine action immédiate : lancez un audit de vos dépôts publics et privés à la recherche de placeholders non réservés. Remplacer third-party[.]com, yoursite[.]com et leurs équivalents par des domaines IANA ou vos propres domaines maîtrisés. Et formez vos équipes à ne jamais copier-coller une commande depuis une page web, même si celle-ci semble légitime.

Nous remercions les équipes de Manifold Security et les chercheurs Ax Sharma et Cody Nash pour leurs analyses détaillées, ainsi que VirusTotal pour les alertes en temps réel.