⚠️ Un error de una letra: el ataque que comprometió 47,000 builds en GitHub

A veces, basta con una sola letra mal escrita para abrirle la puerta a un hacker.
Eso fue justo lo que pasó con un paquete malicioso en npm que imitaba a uno de los módulos más usados por desarrolladores en GitHub Actions.
Y sí, miles de proyectos lo descargaron sin darse cuenta.

🧩 El caso: un ataque de typosquatting en npm

Investigadores de seguridad descubrieron un paquete llamado “@acitons/artifact” (sí, con la “t” y la “i” invertidas).
A simple vista, parece el legítimo “@actions/artifact”, usado en miles de flujos de trabajo de CI/CD en GitHub.
Pero este impostor fue malicioso desde el inicio: fue publicado el 29 de octubre de 2025 y alcanzó más de 47,000 descargas antes de ser eliminado.

🧠 Cómo funcionaba el ataque

El paquete estaba diseñado para ejecutarse durante el proceso de compilación (build), aprovechando el entorno de GitHub Actions donde se ejecutan flujos automatizados de integración y despliegue.
Una vez dentro, su función era robar los tokens de acceso presentes en ese entorno —esos mismos tokens que los desarrolladores usan para subir artefactos, acceder a repositorios o ejecutar acciones privilegiadas.

Con esos tokens, el malware podía haciéndose pasar por GitHub mismo, subir artefactos maliciosos o modificar el contenido de builds legítimos.

🧪 Qué descubrió Veracode

La investigación de Veracode encontró seis versiones maliciosas del paquete, todas con un gancho post-instalación que descargaba y ejecutaba malware externo.
Ese malware pasaba desapercibido para los antivirus más comunes y verificaba variables específicas del entorno de GitHub Actions, buscando credenciales y metadatos sensibles.
Después, cifraba los datos y los enviaba a un subdominio controlado por los atacantes.

Lo más curioso: apuntaba a repositorios propiedad de GitHub y a un usuario de prueba sin actividad pública, lo que sugiere una campaña de reconocimiento o infiltración en cadena.

🧱 Lo que nos enseña este ataque

Aunque las versiones maliciosas fueron eliminadas, el incidente vuelve a mostrar el talón de Aquiles del desarrollo moderno: la cadena de suministro de software.
En un mundo donde automatizamos todo —builds, test, deploy—, un paquete malicioso en npm puede comprometer cientos de proyectos con un solo push.

Y lo peor: este tipo de ataques no apuntan a usuarios comunes, sino a desarrolladores y sistemas automatizados, donde un token expuesto puede equivaler a acceso root al ecosistema completo.

🧰 Qué deberías hacer hoy mismo si trabajas con GitHub Actions o npm

1. 🔍 Revisa tus dependencias: usa herramientas como npm audit, Snyk o Dependabot para detectar paquetes sospechosos.

2. 🧾 Activa verificación de firma: habilita la validación de paquetes con firmas digitales o usa npm pkg verify.

3. 🔐 Restringe tokens: limita el alcance de los tokens de acceso (usa fine-grained tokens o variables temporales).

4. 🧱 Segmenta permisos: nunca uses tokens con privilegios globales en flujos de CI/CD.

5. 🚨 Monitorea tus pipelines: configura alertas para ejecuciones fuera de horario o builds que modifiquen archivos inesperados.

6. 🧰 Revisa hooks post-install: cualquier dependencia con scripts automáticos debe pasar por revisión manual o sandbox.

⚙️ Lección para desarrolladores y sysadmins

Este caso de typosquatting —una simple confusión de letras— demuestra cómo la confianza ciega en los paquetes open source puede convertirse en un riesgo sistémico.
Hoy los atacantes ya no buscan vulnerar el servidor: prefieren colarse en tu pipeline y comprometer el código antes de que llegue al cliente.

Así que, la próxima vez que instales una dependencia, recuerda:
💡 “npm install” no debería ser un acto de fe.