Domaine réservé third-party.com : une attaque ClickFix cible 1 700+ dépôts GitHub et menace les tests logiciels

**En septembre 2026, les équipes de sécurité ont découvert une menace inédite : un domaine banal, third-party[.]com, utilisé depuis des années comme simple espace réservé dans la documentation technique, avait été enregistré et transformé en vecteur d’attaque via la technique ClickFix. Ce domaine apparaissait dans plus de 1 700 dépôts publics GitHub, y compris dans des compétences d’agents d’IA, ce qui ouvre la voie à des injections de commandes et à des compromissions en chaîne. Comment un tel scénario a-t-il pu se produire, et surtout, comment les équipes de développement et de sécurité peuvent-elles se protéger ? Cet article décortique l’attaque, ses implications pour la supply chain logicielle, et fournit des mesures concrètes de remédiation.

La technique ClickFix : des faux correctifs qui installent un logiciel malveillant

La technique ClickFix est une forme d’ingénierie sociale où un site web légitime ou compromis affiche une fausse notification - alerte de sécurité, demande de vérification CAPTCHA ou message d’erreur système - incitant l’utilisateur à copier une commande et à l’exécuter localement pour « résoudre le problème ». En pratique, l’utilisateur se voit demander d’ouvrir la fenêtre Exécuter de Windows (ou le terminal macOS) et de coller le contenu du presse-papier.

« Les pages web utilisant ClickFix exploitent souvent le pastejacking : elles modifient automatiquement le presse-papier de la victime pour y injecter un script malveillant avant que l’utilisateur ne le colle. » - Ax Sharma, Head of Research, Manifold Security.

Dans le cas de third-party[.]com, les visiteurs utilisant un navigateur Windows se voyaient présenter une vérification Cloudflare factice. Le presse-papier était alors empoisonné avec une commande PowerShell qui, une fois exécutée, téléchargeait et lançait une charge utile distante. Les utilisateurs macOS, eux, voyaient un message indiquant que le site n’était pas compatible : « macOS is not supported. This website requires a Windows PC to access. » Ce ciblage sélectif démontre une maturité technique de l’attaquant, qui adapte sa réponse en fonction du système d’exploitation.

Pourquoi cette technique est-elle particulièrement redoutable ? Parce qu’elle contourne les analyses statiques classiques. Un fichier, un scan antivirus ou une analyse de dépôt ne peut pas détecter ce que le serveur décide de renvoyer au moment de la requête. La menace ne se révèle qu’à l’exécution, depuis le navigateur de la cible.

Exemple concret : scénario d’infection typique

1. Un développeur consulte la documentation d’une API sur un site de test qui référence third-party[.]com comme point de terminaison d’exemple.
2. Le navigateur charge la page, mais le domaine résolu appartient désormais à l’attaquant.
3. Le serveur détecte un agent utilisateur Windows et renvoie le leurre ClickFix.
4. Le développeur suit les instructions : il ouvre la boîte de dialogue Exécuter, colle la commande et exécute.
5. La commande PowerShell télécharge un malware qui peut compromettre l’ensemble du poste de travail et, via les accès au dépôt Git, propager l’attaque à la supply chain logicielle.

Cet enchaînement illustre parfaitement le danger des domaines réservés non sécurisés.

third-party.com : de la documentation à la menace active

Le domaine third-party[.]com était utilisé depuis des années comme espace réservé générique, à l’instar de example.com. La différence fondamentale est que example.com est réservé par l’IANA (Internet Assigned Numbers Authority) et ne peut être enregistré. third-party.com, en revanche, n’était pas réservé. N’importe qui pouvait l’acquérir, et c’est exactement ce que des acteurs malveillants ont fait, probablement en 2026.

D’après les analyses de Manifold Security, le domaine sert le leurre ClickFix depuis au moins juin 2026. Les équipes de sécurité ont rapidement marqué le domaine comme malveillant sur VirusTotal et dans la liste Google Safe Browsing, mais le mal était déjà fait.

Une présence massive dans les dépôts GitHub

Une recherche sur GitHub a révélé que third-party[.]com était référencé dans plus de 1 700 dépôts publics. On y trouve des documentations de projets open source, des fichiers de test, des configurations de CI/CD, et surtout des compétences (skills) d’agents d’IA et des serveurs MCP (Model Context Protocol) qui utilisaient ce domaine comme exemple de point de terminaison.

« Dans chacun de ces endroits, il s’agissait exactement de ce qu’il semblait être : un espace réservé, un exemple, un substitut, et une utilisation tout à fait raisonnable de la part des équipes concernées. Mais il s’agit désormais d’un pointeur actif vers un serveur ClickFix. » - Ax Sharma.

Cette armement d’un domaine de confiance aveugle crée une vulnérabilité de type supply chain : un développeur qui inclut une dépendance ou suit une documentation référençant ce domaine s’expose sans le savoir. Pour les agents d’IA, les conséquences peuvent être encore plus graves : le domaine peut servir de point d’injection de prompt, permettant à l’attaquant de modifier le comportement de l’agent.

Treize autres domaines réservés compromis : une menace systémique

Suite à la découverte de third-party[.]com, Manifold Security a étendu ses recherches et identifié 13 autres domaines non réservés par l’IANA, couramment employés comme espaces réservés. Deux d’entre eux se sont avérés actifs : your-domain[.]com et yoursite[.]com. Ces domaines affichaient des contenus malveillants différents selon le système d’exploitation du visiteur.

Comportements observés

• your-domain[.]com : sur macOS, le site affichait un faux « Centre de sécurité macOS » annonçant la présence de quatre virus et proposant un faux renouvellement McAfee à 55 % de réduction. Sur d’autres navigateurs, il renvoyait une simple page parking inoffensive.
• yoursite[.]com : présentait un faux article de ZDF (chaîne de télévision allemande) faisant la promotion d’un système d’investissement frauduleux, toujours sur macOS, tandis que les autres visiteurs voyaient une page neutre.

« Les escroqueries et les peur-ware (scareware) constituent une menace de moindre niveau que les logiciels malveillants par presse-papier, mais l’exposition qu’elles exploitent est bien plus large, et rien de tout cela n’est apparu dans les vérifications statiques que nous avons effectuées. » - Cody Nash, chercheur en sécurité, Manifold Security.

La liste complète des domaines identifiés, tous capables de passer des vérifications statiques (l’analyse d’un fichier ne révèle rien), est la suivante :

Selon les chercheurs, ces deux domaines actifs sont présents dans des centaines de milliers de fichiers GitHub et des centaines de compétences d’agents. Le risque de propagation est exponentiel.

Comment se protéger : mesures pour les développeurs et les équipes sécurité

Face à cette menace, il ne suffit pas de bannir un seul domaine. Les entreprises doivent adopter une démarche systématique pour éviter d’utiliser des espaces réservés non sécurisés dans leur code, leur documentation, et leurs configurations.

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

L’IANA (Internet Assigned Numbers Authority) réserve plusieurs domaines pour la documentation et les tests, notamment :

• example.com, example.org, example.net
• test.com (réservé à certains usages)
• .invalid, .local, .localhost, .test (TLD réservés)

Recommandation : N’utilisez jamais un domaine qui n’est pas explicitement réservé. Remplacez tout third-party[.]com, your-company[.]com, myapp[.]com, etc., par example.com ou un sous-domaine de example.com.

2. Auditer l’intégralité de vos dépôts et artefacts

• Lancez une recherche textuelle dans l’ensemble de vos dépôts Git (private et public), vos fichiers de documentation, vos pipelines CI/CD, vos fichiers de test, et vos conteneurs Docker.
• Cherchez des motifs comme third-party.com, your-domain.com, yoursite.com, myapp.com, ainsi que les variantes avec point remplacé par [.] ou écrit en toutes lettres.
• Utilisez des outils automatisés (grep, semgrep, ou scanners de secrets) pour détecter ces patterns.
• Pour les compétences d’agents d’IA (skills MCP, plugins), vérifiez les endpoints déclarés dans les fichiers de configuration.

3. Mettre en place une politique de validation dynamique

Les analyses statiques ne suffisent pas : un domaine peut sembler inoffensif dans un fichier, mais servir du contenu malveillant à l’exécution. Mettez en place des vérifications dynamiques lorsqu’un domaine externe est utilisé dans un contexte sensible :

• Effectuez une requête HTTP depuis un environnement Windows (ou un navigateur configuré avec un user-agent Windows) pour voir ce qui est réellement renvoyé.
• Intégrez cette vérification dans vos tests de sécurité CI/CD.
• Utilisez un résolveur DNS de confiance et vérifiez l’enregistrement WHOIS pour vous assurer que le domaine n’est pas récent ou suspect.

4. Former les équipes aux risques des placeholders

De nombreux développeurs ne savent pas que example.com est réservé et que d’autres domaines comme third-party.com ne le sont pas. Organisez des sessions de sensibilisation et intégrez cette règle dans vos conventions de code. La cybersécurité commence par les bonnes pratiques de nommage.

5. Surveiller l’apparition de nouveaux domaines réservés non sécurisés

La liste de Manifold Security (13 domaines) est une première alerte. Les attaquants peuvent enregistrer n’importe quel nom de domaine couramment utilisé dans la documentation technique. Mettez en place une veille active :

• Consultez les bulletins de l’ANSSI et du CERT-FR.
• Abonnez-vous aux flux de menaces comme ceux de Manifold Security ou de groupes de recherche (ex. : SANS ISC).
• Utilisez des listes de blocage de domaines malveillants mises à jour quotidiennement (par ex. les listes de PhishTank, OpenPhish, ou les flux de votre fournisseur de sécurité).

Tableau récapitulatif des actions prioritaires :

Implications pour la cybersécurité des entreprises : une faille dans la supply chain

L’attaque via third-party.com démontre que la menace ne se limite pas aux vulnérabilités techniques classiques (buffer overflow, injections SQL). Elle repose sur une défaillance de confiance dans un artefact banal : un nom de domaine de documentation. Cette attaque s’inscrit dans la catégorie des attaques sur la supply chain logicielle, au même titre que l’injection de code malveillant dans des dépendances open source.

Impact sur les référentiels et normes

• ISO 27001 : La norme de management de la sécurité de l’information impose une gestion des risques liés aux fournisseurs et aux ressources externes. L’utilisation de domaines non réservés doit être identifiée comme un risque et traitée dans le plan d’action.
• ANSSI : Le guide de sécurisation du développement web (publié par l’Agence nationale de la sécurité des systèmes d’information) recommande l’utilisation de « noms de domaine de test réservés » (recommandation R.31). Les équipes doivent vérifier leur conformité.
• RGPD : En cas de compromission via ClickFix menant à une fuite de données personnelles, les sanctions peuvent atteindre 4 % du chiffre d’affaires annuel mondial. Le principe d’accountability (responsabilité) exige que les organisations aient mis en œuvre des mesures techniques appropriées.

Le défi des agents d’IA et des environnements MCP

Les agents d’IA (IA générative, assistants de code, robots conversationnels) sont de plus en plus utilisés pour automatiser des tâches. Leurs compétences (skills) sont souvent développés rapidement, avec des endpoints de test pointant vers des domaines comme third-party.com. Un agent qui reçoit une instruction et résout un endpoint peut être la cible d’une prompt injection si le domaine sert du contenu malveillant. Dans le cas de Manifold Security, la découverte de 13 domaines supplémentaires inclut plusieurs noms typiques utilisés pour les API de test (votre-app.com, myapp.com). La menace est réelle et immédiate.

Que faire si vous développez des skills pour assistants d’IA ?

1. N’utilisez jamais de domaine réel pour les exemples. Préférez http://example.com/api avec des données factices.
2. Si vous devez utiliser un endpoint réel, créez un sous-domaine sous un domaine que vous contrôlez (par exemple test.monentreprise.com).
3. Vérifiez dynamiquement que le domaine de test ne renvoie pas de contenu malveillant.
4. Signalez les domaines suspects à votre CERT ou à des plateformes comme le CERT-FR (France) ou ENISA (Europe).

Conclusion : agir dès maintenant pour sécuriser les placeholders

L’attaque sur third-party[.]com n’est pas un incident isolé. C’est un signal d’alarme pour toute l’industrie : les domaines réservés non sécurisés représentent une faille systémique qui touche la documentation, les tests, la formation, et les agents d’IA. La bonne nouvelle, c’est que les correctifs sont simples : adopter exclusivement les domaines réservés par l’IANA, auditer ses bases de code, et former ses équipes.

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

En tant que professionnel de la cybersécurité, vous devez agir dès aujourd’hui. Commencez par une recherche de third-party.com et your-domain.com dans vos dépôts. Remplacez-les par example.com. Mettez en place une politique d’utilisation des noms de domaine réservés. Et surtout, ne faites pas confiance à un domaine simplement parce qu’il est utilisé partout : la cybersécurité moderne exige une vigilance dynamique, pas seulement une analyse statique.

En résumé :

• Le domaine third-party.com a été enregistré par un attaquant et sert un leurre ClickFix aux utilisateurs Windows.
• Il est référencé dans plus de 1 700 dépôts GitHub et des centaines de compétences d’IA.
• 13 autres domaines réservés non sécurisés ont été identifiés, dont deux actifs diffusant des escroqueries et des scareware.
• Les mesures de protection incluent l’utilisation exclusive de domaines IANA-réservés, l’audit complet du code et la mise en place de tests dynamiques.
• Cette attaque illustre l’importance d’une hygiène numérique rigoureuse dans la supply chain logicielle.

Ne laissez pas un simple espace réservé compromettre votre sécurité. Mettez à jour vos pratiques dès maintenant.