Domaine placeholder third-party[.]com : une menace ClickFix silencieuse pour 1 700 dépôts GitHub

En septembre 2026, plus de 1 700 dépôts publics sur GitHub contiennent une référence vers un domaine désormais jugé malveillant : third-party[.]com. Ce domaine placeholder, utilisé depuis des années comme exemple dans la documentation technique, a été enregistré par un attaquant et sert désormais à diffuser du contenu malveillant via la technique ClickFix. La menace du domaine placeholder third-party[.]com cible spécifiquement les systèmes Windows, tandis que les autres visiteurs ne voient qu’un leurre inoffensif. Dans cet article, nous analysons en profondeur ce détournement, ses implications pour la sécurité des chaînes d’approvisionnement logicielles et, surtout, les mesures concrètes que vous pouvez mettre en œuvre pour protéger vos projets.

Comment un simple placeholder est devenu une plateforme d’attaque

Le piège de la confiance aveugle envers les domaines non réservés

Pendant des années, le domaine third-party[.]com a joué le rôle de placeholder générique dans la documentation technique, 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 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’a codé en dur pointe désormais ses lecteurs vers une infrastructure d’attaquant. »

Ce constat met en lumière une vulnérabilité systémique : la confiance aveugle accordée à des noms de domaine qui semblent inoffensifs mais qui ne sont protégés par aucune réservation officielle. De nombreux développeurs, rédacteurs de documentation et concepteurs d’agents d’IA ont intégré third-party[.]com dans leurs fichiers sans jamais vérifier s’il pouvait être enregistré par un tiers malveillant. Cette pratique, bien que compréhensible, expose aujourd’hui des milliers de projets.

ClickFix : la technique d’ingénierie sociale utilisée pour piéger les utilisateurs

L’attaque repose sur une méthode de social engineering appelée ClickFix. Le principe est simple : un site web - légitime ou compromis - affiche un faux message d’erreur, une alerte de navigateur ou une vérification CAPTCHA. L’utilisateur est invité à copier une commande et à l’exécuter dans la fenêtre d’exécution Windows (ou le terminal macOS) pour « résoudre le problème ». En réalité, cette commande injecte un script malveillant.

Dans le cas de third-party[.]com, la page affiche une fausse vérification Cloudflare pour les visiteurs Windows. Le presse-papier de la victime est automatiquement empoisonné avec une commande PowerShell qui télécharge et exécute une charge utile distante. Les utilisateurs de macOS voient quant à eux un message leur indiquant que le site n’est pas supporté, ce qui constitue un leurre destiné à ne pas éveiller les soupçons.

« Une analyse de fichier ne peut pas voir ce qu’un site décide d’envoyer. Le signal n’apparaît qu’au moment de la requête, depuis l’appelant qui compte. » - Manifold Security

Cette capacité à diffuser un contenu différent selon le système d’exploitation et le navigateur rend la détection très difficile par des outils de sécurité statiques. Les scanners qui résolvent le domaine depuis une machine Linux ou Mac ne verront jamais la charge malveillante.

L’ampleur réelle de la menace : 1 700 dépôts GitHub et 13 autres domaines identifiés

L’audit de Manifold Security : des chiffres alarmants

Les chercheurs de Manifold Security ont mené un audit systématique. Ils ont découvert que le domaine third-party[.]com est référencé dans plus de 1 700 dépôts publics sur GitHub, y compris dans des skills d’agents d’IA et des fichiers de documentation de serveurs MCP (Model Context Protocol). Comme le note Ax Sharma : « Dans chacun de ces endroits, c’est exactement ce à quoi cela ressemble : un placeholder, un exemple, un substitut, et une utilisation tout à fait raisonnable de la part des équipes impliquées. C’est aussi, désormais, un pointeur direct vers un serveur ClickFix. »

Parmi ces dépôts, on trouve aussi bien des tutoriels que des configurations d’API, des tests unitaires et des exemples de code pour frameworks. L’impact potentiel est donc colossal, d’autant que ces références sont souvent intégrées dans des chaînes d’intégration continue (CI/CD) ou reprises dans des documentations officielles.

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

Les recherches ne se sont pas arrêtées à third-party[.]com. Manifold Security a depuis identifié 13 autres domaines placeholders qui ne sont pas réservés par l’IANA et qui présentent le même risque. Deux d’entre eux - yoursite[.]com et your-domain[.]com - servent déjà des contenus frauduleux.

« Sur un navigateur macOS, your-domain[.]com affichait un faux « MacOS Security Center » prétendant détecter quatre virus et proposant un renouvellement contrefait de McAfee à 55 % de réduction. Sur un autre rendu macOS, yoursite[.]com montrait un faux article du ZDF faisant la promotion d’un programme d’investissement. » - Cody Nash, chercheur en sécurité

Voici la liste complète des 13 domaines identifiés :

Selon Cody Nash, les deux sites malveillants sont présents dans des centaines de milliers de fichiers GitHub et dans des centaines de skills d’agents. « Les scarewares et les fraudes à l’investissement représentent une menace moindre que les malwares par presse-papier, mais leur exposition est bien plus large, et rien de tout cela n’apparaissait dans les vérifications statiques que nous avons effectuées. »

Pourquoi les analyses de sécurité statiques ne suffisent pas

La dissimulation par différenciation de réponse

L’un des enseignements majeurs de cette découverte est l’échec des méthodes de détection traditionnelles. Les outils de sécurité qui analysent les dépendances ou les URLs dans le code source effectuent généralement une résolution DNS et une requête HTTP pour examiner le contenu. Or, si l’analyse est menée depuis une machine non Windows (Linux, Mac, ou simplement avec un user-agent différent), le serveur malveillant répond par un contenu inoffensif. La charge malveillante n’est servie qu’aux requêtes provenant d’un navigateur Windows.

De même, les analyses statiques de code qui parcourent les fichiers YAML, JSON ou Markdown ne peuvent pas détecter la dangerosité d’un domaine dont le contenu est dynamique et conditionné. Comme le souligne Manifold Security : « Un scan de fichier ne peut pas voir ce qu’un site décide d’envoyer. Le tell n’apparaît qu’au moment de la requête, depuis l’appelant qui compte. »

Conséquences pour l’écosystème open source et les entreprises françaises

Cette faille expose particulièrement les entreprises qui intègrent des composants open source dans leurs chaînes de développement. En France, où l’ANSSI recommande une vigilance accrue sur la sécurité des chaînes d’approvisionnement logicielles, ce type de menace représente un cas d’école. Imaginez une PME française spécialisée dans l’intelligence artificielle qui utilise un skill d’agent référençant third-party[.]com. Lorsqu’un employé exécute une documentation ou un test, son navigateur Windows est redirigé vers le site malveillant. En quelques secondes, le poste peut être compromis, ouvrant la porte à un vol de données, à un rançongiciel ou à un accès durable au réseau interne.

De plus, les agents d’IA qui consomment ces références peuvent être victimes d’injection de prompt indirecte : un attaquant pourrait manipuler le contenu du domaine pour faire dévier le comportement d’un agent, par exemple en lui faisant exécuter des actions non prévues.

Guide pratique : comment sécuriser vos projets face à la menace des placeholders squattables

Face à ce risque émergent, il est impératif d’adopter une démarche proactive. Voici les mesures concrètes que vous pouvez mettre en œuvre dès aujourd’hui.

1. Auditer l’intégralité de vos référentiels

Recherchez dans vos dépôts de code, documentation, fichiers de configuration et workflows CI/CD toute occurrence de domaines placeholders non réservés. Utilisez des commandes comme grep ou des outils d’analyse statique avancés (CodeQL, Semgrep). Les motifs à rechercher incluent :

• third-party.com
• yourdomain.com, yoursite.com, yourapp.com
• myapp.com, mysite.com, mycompany.com
• acme.com, company.com, vendor.com, foo.com
• tout domaine composé de mots génériques suivi de .com, .net, .org non explicitement réservé

Conseil : automatisez cette recherche dans votre intégration continue (CI) pour détecter toute nouvelle introduction de tels placeholders. Une simple règle dans votre linter peut bloquer des merges.

2. Remplacer tous les placeholders non réservés par des valeurs réservées

Les seuls domaines dont vous pouvez garantir qu’ils ne seront jamais enregistrés sont ceux réservés par l’IANA dans la RFC 2606. Utilisez exclusivement :

• example.com
• example.net
• example.org
• test.example
• localhost (pour les adresses locales)
• 0.0.0.0 ou 127.0.0.1 pour les adresses IP

Voici un exemple de code (fichier YAML de documentation) montrant la bonne et la mauvaise pratique :

# ❌ Mauvais : domaine non réservé
endpoint: "https://third-party.com/api/v1"

# ✅ Bon : domaine réservé par l'IANA
endpoint: "https://example.com/api/v1"

Pour les tests unitaires, privilégiez des URLs locales ou des domaines de type *.test.

3. Mettre en place une surveillance dynamique des domaines référencés

Même après avoir nettoyé vos placeholders, il est prudent de surveiller les domaines que vous utilisez dans vos configurations. Des services comme VirusTotal, URLScan ou les flux de threat intelligence de l’ANSSI peuvent vous alerter si un domaine devient malveillant. Pour les projets sensibles, envisagez d’enregistrer vous-même les variantes plausibles de vos noms de domaine afin d’empêcher leur usage frauduleux.

4. Sensibiliser les équipes de développement et de rédaction technique

La sécurité ne se limite pas aux outils. Expliquez à vos équipes pourquoi l’utilisation de placeholders comme mycompany.com ou yourapp.com est risquée. Formez-les aux bonnes pratiques : toujours vérifier qu’un domaine est réservé avant de l’utiliser dans un exemple, et ne jamais coder en dur une URL externe sans analyse préalable.

Conclusion : une vigilance nécessaire face à une menace évolutive

Le détournement de third-party[.]com illustre une nouvelle classe de menaces : l’exploitation de la confiance implicite accordée aux placeholders. Avec plus de 1 700 dépôts GitHub exposés et 13 autres domaines à risque, dont deux déjà actifs, les organisations doivent revoir leurs pratiques de référencement. Les analyses statiques seules ne suffisent plus ; une approche dynamique et une culture de la sécurité sont indispensables.

Ne laissez pas un simple placeholder devenir la porte d’entrée de vos systèmes. Examinez dès maintenant vos référentiels, remplacez les domaines non réservés, et intégrez ces contrôles dans vos processus de développement. La menace du domaine placeholder third-party[.]com n’est que la partie émergée de l’iceberg : d’autres squatteurs pourraient rapidement suivre l’exemple.