El 29 de abril de 2026, el mantenedor del paquete, identificado con el nombre de usuario “sh20raj”, comenzó a lanzar cuatro nuevas versiones en rápida sucesión. Las versiones 2.0.4 a 2.0.7 se publicaron en un lapso de 27 minutos, y cada una incluía código diseñado para robar silenciosamente los archivos “.env” de las máquinas de los desarrolladores en el momento de la instalación. Analistas de Socket.dev identificaron la amenaza mediante detección automatizada impulsada por IA, señalando el comportamiento malicioso en el script *postinstall* integrado en el paquete. Un análisis técnico completo confirmó que las cuatro versiones compartían la misma infraestructura de exfiltración, lo que apuntaba a un único actor detrás del ataque, en lugar de una compromisión gradual o accidental. El impacto de este ataque va más allá de un simple error tipográfico. Tanner Linsley, creador de TanStack, confirmó a los investigadores de Socket que el mantenedor del paquete sin ámbito “tanstack” no tiene conexión con el proyecto oficial TanStack. Linsley reveló que TanStack ha presentado documentos legales relacionados con una reclamación pendiente por infracción de marca registrada contra el mantenedor del paquete. 

 También reveló que el mantenedor había exigido previamente $10,000 a Linsley, y que TanStack había hecho repetidos intentos para que npm tomara medidas, todos sin éxito. Este ataque es un claro ejemplo de una grave amenaza en la cadena de suministro que muchos desarrolladores tienden a pasar por alto. Cualquiera que busque herramientas de TanStack o copie comandos de instalación desde tutoriales podría instalar fácilmente el paquete equivocado sin darse cuenta. Cualquier archivo “.env”, “.env.local” o “.env.production” presente en la carpeta del proyecto en el momento de la instalación debe considerarse completamente comprometido, ya que estos archivos suelen contener claves API, contraseñas de bases de datos y tokens de autenticación que son críticos para la seguridad de la aplicación.

Script Postinstall: Cómo Funcionó el Ataque

El núcleo de este ataque residía en los scripts *postinstall* del paquete. Cuando un desarrollador ejecutaba “npm install”, el script se activaba automáticamente y comenzaba a escanear el directorio raíz del proyecto en busca de archivos de variables de entorno. La función maliciosa, llamada “collectEnvFiles()”, recopilaba todos los archivos que coincidían con los patrones “.env” o “.env.*” y los empaquetaba en una carga útil JSON. Esta carga útil se enviaba luego mediante una solicitud HTTPS POST a un endpoint alojado en Svix, un servicio de entrega de webhooks de terceros controlado por el atacante. 

 

Para ocultar su verdadero propósito, la función recibió un nombre inocente, “sendReadme()”, lo que la hacía parecer telemetría rutinaria a primera vista. La versión 2.0.6 fue la más agresiva, escaneando todo el directorio de instalación en busca de todas las variantes “.env.*” y enviándolas silenciosamente sin dejar rastro visible. La versión 2.0.7 redujo ligeramente su alcance, pero comentó todas las llamadas a *console.log*, dificultando aún más su detección por parte de las herramientas de seguridad. El atacante utilizó una fuente de webhook de Svix con el ID “src_3387PLMB2uhXOBe3Q8sHu” como buzón de entrega unidireccional para los datos robados. Cualquiera podía enviar datos a la URL pública de ingesta, pero solo el titular de la cuenta autenticada podía leer lo que llegaba, lo que dificultaba a los defensores verificar qué se había robado. El mismo ID de fuente de Svix apareció en las cuatro versiones maliciosas, confirmando que toda la actividad provenía de un único atacante. Los desarrolladores que instalaron las versiones 2.0.4 a 2.0.7 deben desinstalar el paquete y rotar todos los secretos de inmediato. Cualquier clave API, token o credencial de base de datos almacenada en archivos “.env” afectados debe considerarse completamente comprometida y reemplazarse de inmediato. Los equipos deben auditar sus archivos “package.json”, “package-lock.json” y “yarn.lock” en busca de referencias al paquete sin ámbito “tanstack” y eliminarlo. Las organizaciones también deben agregar el paquete sin ámbito “tanstack” a sus listas de denegación de registro y monitorear el tráfico saliente hacia “api.svix.com” desde máquinas de desarrolladores, pipelines de CI/CD y entornos de construcción de contenedores. Siempre instala los paquetes de TanStack utilizando el formato oficial con ámbito “@tanstack/*” para evitar caer en trampas similares. Indicadores de Compromiso (IoC):

Campo	Valor
Paquetes Maliciosos	npm/tanstack@2.0.4, 2.0.5, 2.0.6, 2.0.7
Autor en npm	sh20raj
Mecanismo de Activación	hook del ciclo de vida *postinstall* de npm
ID de Fuente Svix	src_3387PLMB2uhXOBe3Q8sHu
URL de Exfiltración	hxxps://api[.]svix[.]com/ingest/api/v1/source/src_3387PLMB2uhXOBe3Q8sHu/

Fuentes:
https://cybersecuritynews.com/malicious-npm-package-brand-squats-tanstack/