Third-party[.]com : comment un simple placeholder est devenu une menace de cybersécurité

Plus de 1 700 dépôts GitHub référencent encore aujourd’hui le domaine third-party[.]com comme exemple ou point de terminaison. Ce qui n’était qu’un générique de documentation, au même titre qu’example.com, a été enregistré par un acteur malveillant et sert désormais à distribuer des malwares via la technique ClickFix. Cette attaque illustre un angle mort majeur de la cybersécurité moderne : la confiance aveugle accordée aux placeholders non réservés.

Dans cet article, nous analysons en détail la compromission du domaine third-party[.]com, le fonctionnement de la chaîne d’attaque ClickFix, l’ampleur de la contamination sur GitHub, ainsi que les leçons à en tirer pour sécuriser vos projets, vos agents d’IA et vos documentations.

Quand un placeholder devient un vecteur d’attaque

Le domaine third-party[.]com était utilisé depuis des années comme espace-réservé dans la documentation, les tests et les configurations, à l’instar d’example.com. Toutefois, contrairement à ce dernier, il n’est pas réservé par l’IANA (Internet Assigned Numbers Authority). Cela signifie que n’importe qui peut l’enregistrer. Et c’est exactement ce qui s’est produit.

Un enregistrement malveillant passé inaperçu

D’après les investigations de Manifold Security, le domaine a été acquis par un attaquant au plus tard en juin 2026. Depuis, il sert un contenu malveillant aux visiteurs utilisant un navigateur Windows, tandis que les autres navigateurs (macOS, Linux) voient une page leurre inoffensive. Ce géotargeting par User-Agent rend la détection statique particulièrement difficile.

« third-party[.]com est un espace-réservé générique depuis des années, le même rôle que joue example.com. Mais contrairement à example.com, il n’est pas réservé par l’IANA. N’importe qui pouvait l’enregistrer, et quelqu’un l’a fait. Désormais, chaque doc, test ou skill qui l’a codé en dur pointe ses lecteurs vers une infrastructure malveillante. » - Ax Sharma, Head of Research chez Manifold Security.

Au moment de la rédaction de cet article, le domaine est classé comme malveillant sur VirusTotal et sur la liste Google Safe Browsing.

La technique ClickFix : un leurre social sophistiqué

L’attaque ne se contente pas d’afficher une simple page piégée. Elle utilise ClickFix, une technique d’ingénierie sociale qui simule un message d’erreur ou une vérification de sécurité.

Comment fonctionne ClickFix ?

1. L’utilisateur Windows arrive sur le domaine third-party[.]com.
2. Une fausse page de vérification Cloudflare apparaît, demandant d’exécuter une action pour « résoudre le problème ».
3. En arrière-plan, un script JavaScript modifie le presse-papier de la victime et y injecte une commande PowerShell malveillante.
4. La victime est invitée à ouvrir la boîte de dialogue Exécuter (Win+R) et à coller le contenu (Ctrl+V).
5. En collant et en validant, elle exécute la commande qui télécharge et lance un payload PowerShell distant.

Cette variante est parfois appelée pastejacking : le contenu du presse-papier est subtilement remplacé à l’insu de l’utilisateur.

« Un scan de fichier ne peut pas voir ce qu’un site web choisit d’envoyer. Le signe n’apparaît qu’au moment de la requête, depuis le navigateur qui compte. » - Manifold Security.

Réaction des utilisateurs macOS

Pour les visiteurs depuis un Mac, la page affiche un message leurre :

« macOS n’est pas pris en charge. Ce site nécessite un PC Windows pour y accéder. Veuillez réessayer depuis un appareil Windows. »

Aucune tentative d’infection n’a été observée sur macOS, mais ce comportement confirme que l’attaquant cible spécifiquement les environnements Windows.

L’ampleur de la contamination : plus de 1 700 références sur GitHub

Une recherche sur GitHub révèle que le domaine third-party[.]com est mentionné dans plus de 1 700 dépôts publics, dont beaucoup liés à des skills d’agents d’IA et à des documentations de serveurs MCP (Model Context Protocol).

« Dans chacun de ces endroits, c’est exactement ce qu’il semble être : un espace-réservé, un exemple, un substitut, et une utilisation tout à fait raisonnable de la part des équipes concernées. C’est aussi, désormais, un pointeur vivant vers un serveur ClickFix. » - Ax Sharma.

Cette situation expose un risque nouveau : les agents d’IA qui consultent ces documentations ou exécutent ces skills peuvent, en suivant le lien, déclencher une infection sur le poste de l’utilisateur final. La confiance implicite dans un domaine jugé inoffensif ouvre la porte à des attaques par injection de prompt et à des comportements non désirés.

Pourquoi les solutions de sécurité classiques échouent

• Analyse statique : un scan d’un fichier source ne voit qu’une URL inoffensive. Rien n’indique que le domaine est devenu malveillant.
• Analyse dynamique depuis une boîte d’analyse : si la boîte utilise un User-Agent non Windows, elle reçoit la page leurre et conclut que le domaine est sûr.
• Listes de blocage : même avec une mise à jour rapide, le laps de temps entre l’enregistrement malveillant et la détection laisse une large fenêtre d’exploitation.

13 autres domaines placeholders à risque

Suite à cette découverte, Manifold Security a identifié 13 autres domaines génériques également non réservés par l’IANA. Parmi eux, deux servent déjà des contenus malveillants : yoursite[.]com et your-domain[.]com.

Tableau récapitulatif des 13 domaines placeholders non réservés

« Les arnaques par scareware et les fraudes à l’investissement constituent une menace moins élevée que les malwares par presse-papier, mais l’exposition qu’elles exploitent est bien plus large, et rien de tout cela n’apparaissait dans nos vérifications statiques. » - Cody Nash, chercheur chez Manifold Security.

Ces deux domaines malveillants sont présents dans des centaines de milliers de fichiers GitHub et des centaines de skills d’agents. Le risque est donc massif.

Recommandations pour les développeurs et les équipes de sécurité

Face à ce type de menace, les bonnes pratiques doivent évoluer. Voici les mesures à mettre en œuvre dès maintenant.

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

L’IANA a réservé des domaines à des fins de documentation et de test :

• example.com, example.org, example.net
• test.example
• localhost

Aucun autre domaine non réservé ne devrait figurer dans une documentation ou un code source en tant qu’espace-réservé. Ne jamais employer des noms comme yourcompany.com, myapp.com ou third-party.com.

2. Auditer l’ensemble de vos bases de code et documentations

• Recherchez les occurrences des 13 domaines listés ci-dessus, ainsi que toute autre URL qui ne serait pas sous votre contrôle.
• Utilisez des outils de SCA (Software Composition Analysis) ou des scripts grep pour identifier les références à ces placeholders.
• Pour chaque occurrence, remplacez-la par un domaine réservé de l’IANA ou, mieux, par un nom de domaine que vous possédez réellement pour vos tests.

3. Renforcer la sécurité des agents d’IA et des skills

• Les skills qui intègrent des URLs en dur doivent être revus en priorité.
• Implémentez une validation dynamique : avant de suivre un lien, vérifiez sa réputation via une API (Safe Browsing, VirusTotal) en temps réel, et non pas seulement lors de la création du skill.
• Considérez que tout domaine externe non réservé peut être enregistré à tout moment par un attaquant.

4. Surveiller les nouveaux enregistrements de domaines placeholders

• Mettez en place une veille sur les noms de domaine correspondant à des placeholders courants (listes partagées par Manifold Security ou d’autres chercheurs).
• Abonnez-vous aux flux de détection de domaines malveillants (ex. : URLhaus, PhishTank).

5. Former les équipes aux risques des placeholders

• Organisez une session de sensibilisation dédiée aux angles morts des domaines de confiance.
• Expliquez la différence entre example.com (réservé) et third-party.com (non réservé).

Conclusion : une leçon sur la confiance implicite

La compromission de third-party[.]com n’est pas un incident isolé : elle révèle une vulnérabilité structurelle dans la manière dont nous utilisons les placeholders. Ces domaines, parce qu’ils sont largement référencés dans des documentation, tests et configurations, offrent aux attaquants une porte d’entrée massive.

Les techniques comme ClickFix ou pastejacking rendent l’attaque encore plus redoutable, car elles contournent les analyses statiques et dynamiques classiques. Le fait que deux autres domaines soient déjà actifs prouve que le phénomène n’en est qu’à ses débuts.

En tant que professionnels de la cybersécurité, vous devez repenser la confiance accordée aux domaines génériques. La solution passe par une discipline stricte : n’utiliser que des domaines IANA réservés, auditer régulièrement vos référentiels, et ne jamais présumer qu’un domaine de démonstration est inoffensif.

Avez-vous déjà audité vos propres projets pour détecter de tels placeholders ? Si ce n’est pas le cas, agissez dès aujourd’hui. La prochaine menace pourrait cibler un domaine que vous utilisez vous-même.

Sources : Manifold Security, VirusTotal, Google Safe Browsing, analyse GitHub - septembre 2026.