Report URI detecta 15.579 webs con JavaScript malicioso

15.579 webs infectadas: el problema que Report URI no puede resolver sola

15.579 sitios web están sirviendo JavaScript malicioso en este momento y, en conjunto, reciben más de 135 millones de visitas al mes. Es la cifra que publica Report URI, la plataforma de monitorización de seguridad de Scott Helme, y viene acompañada de una confesión poco habitual en el sector: la compañía no sabe cómo avisar a los afectados.

El cuello de botella no está en la detección. Está en la notificación. Las capacidades de threat intelligence de Report URI han crecido hasta el punto de que identifican webs comprometidas mucho más rápido de lo que la divulgación responsable puede procesarlas. Y ahí se queda todo atascado.

Para un founder con producto digital, la lectura es incómoda: si tu web carga un script de terceros, tu superficie de ataque ya no es tu código. Es toda la cadena que hay detrás.

¿Y esto cómo se aplica en tu negocio?

Dueños de negocio de Latinoamérica y España usan un agente de IA para ganar más y recuperar su tiempo. El Kit «tu mano derecha con IA» te muestra cómo en un video de 11 minutos, con una ficha para armar el tuyo. CAR está cerrada por ahora; al anotarte, te avisamos cuando abra.

👥 Quiero el Kit →

¿Qué ataques están encontrando en esas webs?

El patrón común es JavaScript que no debería estar ahí. Report URI agrupa las infecciones en cuatro familias:

Skimmers de tarjetas — los conocidos como Magecart, que se instalan en páginas de pago y exfiltran el número completo de tarjeta, la caducidad, el CVV y el nombre del titular.
Ataques ClickFix — pantallas que simulan un «verifica que eres humano» y, en lugar de eso, convencen al usuario de instalar malware en su dispositivo.
Explotación de dispositivos — carga de malware dirigida a versiones concretas de iOS para instalar spyware, con nombres como DarkSword o Coruna.
Redirecciones — el visitante acaba donde el atacante quiere: páginas de login falsas para phish, avisos de seguridad falsos, estafas.

El detalle importante es que el payload cambia según el objetivo. Una misma web infectada puede servir un skimmer a quien llega al checkout y una redirección a quien entra desde un enlace en redes sociales. Eso complica la detección basada en firmas y explica por qué el inventario de sitios afectados se mueve constantemente.

Los cuatro vectores por los que entra el código malicioso

Report URI clasifica el origen de la infección en cuatro categorías. Vale la pena revisarlas una por una, porque cada una exige una defensa distinta:

Compromiso directo. Normalmente una vulnerabilidad de WordPress o un CMS similar. Los propios archivos JS del sitio se modifican para incluir el código malicioso. Aquí el fallo está en tu infraestructura.
Cadena de suministro. Un script de terceros que tu web carga está infectado y se sirve a todos tus visitantes. Tú no cambiaste nada; el proveedor sí.
XSS. Una vulnerabilidad en el propio sitio permite inyectar JavaScript. Es el vector clásico y sigue funcionando.
DeadTag. Un grupo al que Report URI puso nombre recientemente: compran dominios caducados de los que muchas webs todavía cargan scripts, los reactivan y sirven malware desde ahí.

El vector DeadTag es el más silencioso de los cuatro y el más fácil de pasar por alto. Nadie audita los scripts de un dominio que dejó de existir hace tres años.

¿Por qué el aviso responsable no escala?

Report URI notifica directamente los casos de mayor impacto, pero admite que lo hace a pequeña escala. El proceso consume muchos recursos y choca con tres problemas de fondo:

No tienen datos de contacto. Los sitios se descubren rastreando la web, no porque sean clientes. No hay formulario, ni contrato, ni correo de administración verificado.
El uso de security.txt es bajo. Es el estándar pensado exactamente para esto: un archivo en el dominio que indica a quién avisar de una vulnerabilidad. Su adopción sigue siendo escasa.
La mayoría de los mensajes no recibe respuesta. Aunque encuentren un canal, el aviso cae en el vacío.

La consecuencia es un inventario que crece más rápido de lo que se puede vaciar. Report URI retira de la lista los sitios que limpian su propia infección, así que el total real de afectados en algún momento es mayor que los 15.579 actuales. Además de los confirmados, hay miles más con sospecha razonable pero sin certeza al 100%.

El impacto no es proporcional al tamaño del sitio

Uno de los puntos más interesantes del análisis es el perfil de las víctimas. No son las webs globales más grandes. Son líderes regionales: sitios de .fr, .es y .de que apenas entran en el Top 1 Million global pero dominan su mercado local. Un líder en Francia sigue recibiendo muchísimo tráfico.

Eso significa que el riesgo no se concentra en las grandes plataformas con equipos de seguridad dedicados. Se concentra en negocios medianos que nunca imaginaron ser objetivo. Y ahí está el founder hispanohablante: una tienda online o un SaaS con checkout propio en España o LATAM tiene exactamente el perfil que esta lista describe.

Dos casos documentados por BleepingComputer muestran el mismo patrón con nombres y cifras. Un grupo brasileño de skimming comprometió un script de analítica compartido de la plataforma de e-commerce Convertr, inyectando código en el tracker de Plausible que se carga en las páginas de checkout de todos sus comercios. El grupo lleva activo desde al menos julio de 2024 y ataca tiendas en Magento, OpenCart y WooCommerce; Convertr maneja R$2.000 millones (unos US$370M) en ventas. El skimmer robaba número de tarjeta, caducidad, CVV, nombre y CPF. Un solo script de analítica, decenas de comercios expuestos.

El otro caso es más caro. Polymarket reembolsó a los usuarios que perdieron unos US$3M tras la inyección de un script malicioso en su frontend por una brecha en un proveedor externo. Sus servidores y su backend no se vieron afectados: el ataque entró por una dependencia del sitio. La empresa está valorada en US$9.000M según el mismo reporte. Si una plataforma de ese tamaño cae por un vendor, el tamaño no es la defensa.

Y la cadena de suministro de JavaScript no es solo cuestión de dinero. Amazon Web Services evaluó con alta confianza que el actor norcoreano conocido como Sapphire Sleet está detrás del compromiso de paquetes npm como Axios, Debug, Chalk y Typo-Crypto, según reportó BankInfoSecurity. Axios supera los 100 millones de descargas semanales. El vector no es la web de un cliente: es una librería que miles de webs cargan sin pensarlo.

¿Qué significa esto para tu startup?

Tres conclusiones prácticas.

Primera: tu inventario de scripts es tu perímetro real. La mayoría de equipos sabe qué frameworks usa, pero no cuántos scripts de terceros cargan en producción ni quién los mantiene. Ese inventario cambia cada sprint y casi nadie lo revisa.

Segunda: el vector más probable no es un ataque dirigido a ti. Es un proveedor comprometido. Y cuando eso pasa, tus usuarios ven el checkout de tu marca mientras sus datos se van a otro sitio. La confianza se rompe en tu dominio, no en el del proveedor.

Tercera: la notificación no llega sola. Si tu web se infecta, nadie tiene la obligación práctica de avisarte, y quien detecta la infección muchas veces no tiene tu correo. El tiempo entre infección y limpieza lo determina tu propia capacidad de detectar, no la buena voluntad de un tercero.

Acciones concretas para esta semana

Publica un security.txt. Es el canal que Report URI y otros investigadores buscan y no encuentran. Define un correo de seguridad y una política de divulgación en /.well-known/security.txt. Es media hora de trabajo y te pone en el mapa de quien quiere avisarte.
Inventaría y prioriza tus scripts de terceros. Lista cada dominio externo que se carga en producción, quién lo mantiene y qué pasa si desaparece. Empieza por los que tocan checkout, login y páginas con datos personales.
Aplica Subresource Integrity (SRI) a los scripts que puedas. Fija el hash del archivo servido para que el navegador rechace una versión modificada. No sirve para todos los casos —los scripts que se actualizan solos rompen el hash— pero sí para las librerías versionadas.
Monitoriza con CSP en modo reporte. Una Content Security Policy con report-to te avisa cuando el navegador detecta un script que no está en la lista blanca. Es la forma más barata de enterarte de una inyección antes que tus usuarios.
Vigila los dominios caducados en tus etiquetas. Revisa si algún script apunta a un dominio cuyo propietario ya no renueva. Es el vector DeadTag y no requiere que nadie te ataque directamente.
Si operas en Europa y detectas una infección, contacta a tu CERT nacional. Report URI ofrece listas de sitios infectados por región a los NCSC/CERT que escriban a [email protected], y reconoce que ellos probablemente tengan más éxito notificando que la propia empresa.

Conclusión

La noticia no es que haya 15.579 webs infectadas. Es que el sistema de aviso está roto por diseño: quien detecta no tiene el contacto, quien tiene el contacto no detecta, y el estándar creado para cerrar esa brecha —security.txt— se usa poco. Mientras eso siga así, la única persona que puede actuar rápido sobre tu web infectada eres tú.

Report URI tiene la inteligencia para proteger millones de visitas y ha pedido ayuda públicamente para convertirla en acción. Para un founder, la parte accionable de esa petición es simple: hazte localizable antes de que te busquen.