Un dominio que aparecía en 1.700 repositorios se volvió malicioso de repente y comenzó a atacar sistemas Windows.

Un ejemplo común de la documentación se convirtió en un verdadero vector de ataque. El dominio third-party[.]com, que durante años se insertaba en el código como una dirección de ejemplo de un servicio externo, desde al menos junio de 2026 muestra a usuarios de Windows una comprobación falsa de Cloudflare e intenta inducirles a ejecutar por sí mismos un comando malicioso a través de la ventana «Ejecutar».

El problema fue detectado durante la revisión de habilidades públicas de agentes de IA y la documentación de servidores MCP: uno de los archivos enlazaba a third-party[.]com, y el dominio ya había sido marcado como phishing. La comprobación posterior mostró que los documentos originales y los ejemplos de código no habían cambiado. Lo que cambió fue el contenido de la propia dirección, que antes se consideraba un simple marcador de posición.

La evaluación inicial señalaba más de 1500 archivos y 1700 repositorios, incluidos materiales de Chromium, Sanity y Vercel. Más tarde los autores ajustaron la metodología y, con una búsqueda más estricta de URLs, obtuvieron 672 archivos. GitHub considera estos resultados aproximados, por lo que las cifras no deben tomarse como un registro preciso, pero la escala muestra cuánto se había usado el dominio no reservado como ejemplo inofensivo.

En Windows la página imita la comprobación de Cloudflare. JavaScript coloca un comando oculto de PowerShell en el portapapeles, y la instrucción propone pulsar Win+R, pegar el contenido y pulsar Enter. El comando contacta con el dominio elxxvvx[.]xyz, obtiene un script remoto mediante Invoke-RestMethod y lo ejecuta en memoria con Invoke-Expression, al mismo tiempo ocultando los mensajes de error.

A los usuarios de macOS y Linux la misma dirección muestra un marcador aparentemente seguro con el mensaje de que se necesita un equipo con Windows. Esa elección de contenido según el User-Agent ayuda a evadir las comprobaciones automáticas. IPFire incluyó el dominio en la lista de maliciosos el 7 de julio, pero ya el 17 de julio lo eliminó, aunque la página maliciosa seguía funcionando para la plataforma objetivo.

En el momento de la comprobación técnica, el servidor de segunda fase elxxvvx[.]xyz ya no respondía, por lo que la cadena descrita no podía completar la descarga del siguiente componente. El propio third-party[.]com continuó el 23 de septiembre ofreciendo el anzuelo a los usuarios de Windows. No se han registrado casos confirmados en los que un enlace desde un repositorio concreto ya haya provocado la infección de un desarrollador o una aplicación.

El riesgo no consiste en la compromisión de los propios proyectos, sino en la costumbre de tratar direcciones similares como ejemplos neutrales. En Chromium el dominio aparece en la documentación, en Sanity se usó en un ejemplo para Playwright, y en Turborepo de Vercel estaba presente en una prueba de verificación del origen de la petición. Algunas habilidades de agentes de IA incluyen una llamada a third-party[.]com/widget.js, que una herramienta automática podría ejecutar literalmente.

ClickFix se basa precisamente en el paso de un contexto de confianza a un comando que ejecuta el propio usuario. En septiembre los atacantes ya habían suplantado páginas a través de la infraestructura de Cloudflare y mostraban a los visitantes una comprobación falsa con Win+R. En el caso de third-party[.]com lo inusual no es la técnica en sí, sino la fuente de confianza: la dirección durante años se veía como una simple plantilla técnica.

El dominio se registró en 1996, mucho antes de la campaña actual, y no hay datos que indiquen que originalmente tuviera un propósito malicioso. A diferencia de example.com, example.org y example.net, third-party[.]com no está reservado por la IANA para documentación, por lo que su contenido depende del propietario. Cuando la infraestructura de dicho dominio cambia, los ejemplos antiguos de código empiezan automáticamente a apuntar al recurso nuevo.

Se recomienda a los autores de documentación y habilidades usar solo dominios reservados, y revisar los materiales ya publicados en busca de direcciones externas que el equipo no controle. No se aconseja añadir dominios activos desconocidos a listas blancas solo para silenciar advertencias. Para comprobaciones internas de URL también es preferible separar la verificación sintáctica del enlace de la conexión real al servidor externo.