Investigadores de Veracode señalaron un paquete malicioso en npm, @acitons/artifact, que imitaba al legítimo @actions/artifact con el objetivo de explotar entornos de GitHub Actions. Horas después, GitHub confirmó que no se trató de una intrusión real, sino de ejercicios controlados del Red Team para probar la resiliencia de sus procesos internos de seguridad.
Typosquatting y postinstall: cómo operaba la cadena de ataque
El paquete se publicó el 29 de octubre de 2025 y acumuló 47 405 descargas (31 398 en la última semana). La técnica fue un caso clásico de typosquatting: cambiar el orden de letras en el scope (@acitons vs @actions) para aprovechar errores tipográficos al declarar dependencias.
Seis versiones (4.0.12–4.0.17) contenían lógica maliciosa en un postinstall que descargaba un binario llamado harness desde una cuenta de GitHub ya eliminada. Este componente, un script de shell ofuscado, incluía un “temporizador” que desactivaba la carga si la fecha era igual o posterior al 6 de noviembre de 2025.
Tras la instalación, el script ejecutaba verify.js para detectar variables de entorno GITHUB_*, típicas de GitHub Actions. Si se confirmaba el entorno objetivo, procedía a la exfiltración de tokens temporales, cifrados y enviados a un subdominio app.github.dev. El código filtraba por propietario del repositorio y detenía la ejecución si GITHUB_REPOSITORY_OWNER no coincidía con la organización GitHub, lo que evidencia un targeting acotado.
La cuenta blakesdev, que publicó las versiones, fue eliminando los releases maliciosos conforme avanzaba la investigación; permaneció accesible la versión “limpia” 4.0.10. Se detectó además un paquete similar, 8jfiesaf83 (ya retirado), con 1 016 descargas.
Impacto y riesgos: seguridad de la cadena de suministro de software
El caso subraya la fragilidad de la cadena de suministro ante la unión de typosquatting y scripts de instalación. Un postinstall corre automáticamente al instalar dependencias, convirtiendo una simple errata en un punto de intrusión. En CI/CD, un paquete comprometido puede acceder a secretos de pipeline, artefactos de build y tokens temporales con permisos operativos sobre repositorios.
Aunque GitHub indicó que fue un ejercicio realista y controlado —“sistemas y datos de GitHub no estuvieron en riesgo”—, el hecho de que el paquete “de entrenamiento” llegase al registro público de npm y acumulase decenas de miles de instalaciones reaviva preocupaciones ya vistas en incidentes reales como event-stream (2018) o UAParser.js (2021). Informes de la industria (p. ej., Sonatype y ENISA) advierten que los ataques a la cadena de suministro continúan creciendo y profesionalizándose.
Transparencia y límites de los ejercicios de Red Team
Los ejercicios ofensivos en entornos públicos deben equilibrar realismo y mínimo impacto en terceros: scoping preciso, controles de geofencing, revocación rápida de artefactos y tarjetas de garantía (canales de comunicación y desactivación) que reduzcan efectos colaterales sobre desarrolladores ajenos al test.
Medidas prácticas para blindar CI/CD y dependencias
Controles preventivos y de hardening
1) Reducir el riesgo de typosquatting. Usar allowlists de namespaces, repositorios internos/espelhos y plantillas de dependencias; reforzar con code review y automatizaciones.
2) Fijar versiones con rigor. Emplear lockfiles (package-lock.json), npm ci, revisiones periódicas y evitar actualizaciones mayores automáticas.
3) Restringir scripts de ciclo de vida. Desactivar postinstall en CI con npm install –ignore-scripts y permitirlo solo donde sea imprescindible.
4) Endurecer GitHub Actions. Aplicar least privilege al GITHUB_TOKEN, environment protection rules, OIDC para workload identity y políticas de secretos “deny-by-default”.
5) Controlar el egress y monitorizar. Limitar salidas de los runners por allowlist, registrar y alertar tráfico anómalo; incorporar EDR/NSM al entorno de CI.
6) Trazabilidad y verificación. Generar SBOM (p. ej., CycloneDX), verificar integridad de artefactos y adoptar marcos como SLSA para garantizar procedencia.
El episodio de @acitons/artifact recuerda que la confianza en el ecosistema open source exige disciplina operativa: endurecer pipelines, minimizar privilegios, limitar scripts automáticos y validar el origen de cada paquete. Revisar hoy estas prácticas reduce el riesgo de ataques reales y permite afrontar sin sobresaltos futuros ejercicios de seguridad.
