En mayo de 2026, una campaña sofisticada desplegó 148 paquetes de npm disfrazados de proxies web para estudiantes, transformando con éxito los navegadores de usuarios desprevenidos en una botnet de denegación de servicio distribuida (DDoS). Este incidente destaca una evolución peligrosa en los ataques a la cadena de suministro: el cambio de comprometer la tubería de compilación a weaponizar la ejecución del lado del cliente.
1. El abuso "inocente" del registro
Las herramientas tradicionales de Análisis de Composición de Software (SCA) y Pruebas de Seguridad de Aplicaciones Estáticas (SAST) están diseñadas para detectar código malicioso en el momento de la instalación. Esta campaña evadió por completo esos controles. Los paquetes no contenían ganchos de ciclo de vida ni scripts de compilación nativos. En su lugar, actuaron meramente como alojamiento gratuito para una aplicación web del lado del cliente, esperando en silencio hasta que un usuario visitó activamente el sitio proxy para evadir los filtros de red escolares.
2. La vulnerabilidad de la rama mutable
Una vez que el proxy se cargó en el navegador, ejecutó un cargador de scripts remoto que obtenía JavaScript de un repositorio de GitHub a través de una CDN. Críticamente, esta solicitud apuntaba a una rama principal mutable sin ninguna verificación de Integridad de Subrecursos (SRI). Esto permitió a los operadores cambiar la carga útil en silencio a voluntad, ejecutando código con los privilegios de origen del propio sitio proxy y con acceso completo a las cookies y al almacenamiento local.
3. Agotamiento del plano de control sobre inundación volumétrica
Si bien la botnet lanzó inundaciones HTTP crudas, su módulo más sofisticado utilizó el protocolo proxy Wisp para abrir cientos de conexiones WebSocket por navegador. No se trató de un ataque volumétrico tradicional; fue un ataque al plano de control diseñado para agotar los descriptores de archivos e inundar el almacenamiento de registros en el servidor Wisp objetivo, colapsando efectivamente la infraestructura a través de un ciclo legítimo de creación y cierre de conexiones.
5. Defensas estratégicas para una amenaza del lado del cliente
Mitigar esta clase de ataque requiere ir más allá del análisis estático de código. Las organizaciones e instituciones educativas deben implementar Políticas de Seguridad de Contenido (CSP) estrictas para bloquear la ejecución no autorizada de scripts entre orígenes. Además, aplicar la Integridad de Subrecursos (SRI) para todos los scripts externos y desplegar bloqueos a nivel de DNS para hosts de scripts y monetización maliciosos conocidos son controles de línea base innegociables. Para los usuarios afectados, limpiar la caché del navegador, el almacenamiento local y anular el registro de los service workers persistentes es la única forma de romper el mecanismo de persistencia.
Mientras los registros de paquetes públicos puedan ser abusados como Redes de Entrega de Contenido (CDN) gratuitas para aplicaciones del lado del cliente, la superficie de ataque seguirá expandiéndose mucho más allá del entorno de compilación tradicional. Los defensores deben adaptar su monitoreo para detectar comportamientos anómalos en tiempo de ejecución, no solo vulnerabilidades estáticas en el código.