PostHog admite Shai-Hulud 2.0: su mayor fallo de seguridad

PostHog admite Shai-Hulud 2.0: su mayor fallo de seguridad

Compartir:

PostHog afirma que la filtración de Shai-Hulud 2.0 fue ‘el incidente de seguridad más grande e impactante’ que ha experimentado, originado cuando atacantes inyectaron lanzamientos maliciosos en sus SDK de JavaScript y buscaron obtener credenciales de desarrolladores.

En un postmortem publicado por la propia empresa, se indica que los paquetes contaminados —entre ellos posthog-node, posthog-js y posthog-react-native— contenían un script de pre-install script que se ejecutaba al instalar el software. Ese script hacía correr TruffleHog para rastrear credenciales, exfiltraba secretos a nuevos repos públicos de GitHub y luego utilizaba credenciales robadas de npm para publicar paquetes maliciosos, permitiendo que el gusano se propagara.

Según analistas de Wiz, citados por The Register, más de 25,000 desarrolladores vieron comprometidos sus secretos en apenas tres días. Además de PostHog, los paquetes afectados incluyen componentes de Zapier, AsyncAPI, ENS Domains y Postman, entre otros, muchos con decenas de miles de descargas semanales.

El gusano no se limita a propagarse como un troyano típico: una vez instalado un paquete comprometido, el malware puede robar tokens de npm y GitHub, credenciales en la nube (AWS, Azure, GCP), secretos de CI/CD y otras variables de entorno, tanto de máquinas de desarrollo como de sistemas de construcción.

PostHog afirmó revocar todos los tokens comprometidos, eliminar las versiones maliciosas de los paquetes y emitir versiones ‘conocidas y seguras’. Sin embargo, el informe destaca un peligro estructural: no se trató simplemente de una fuga accidental de contraseñas, sino de una configuración defectuosa de CI/CD que permitió que código de un pull request malicioso se ejecutara con privilegios elevados.

Como medidas de endurecimiento, PostHog dice que adoptará un modelo de ‘trusted publisher’ para lanzamientos en npm, revisará exhaustivamente los cambios de flujos de trabajo y deshabilitará la ejecución de scripts de instalación en sus pipelines de CI/CD, entre otras acciones.

Si este postmortem os suena familiar, es porque refleja una realidad creciente: bots con grandes permisos, flujos de trabajo que actúan en piloto automático y dependencias que se actualizan con la impetuosidad de un becario que no leyó la documentación. En definitiva, eso es exactamente lo que un gusano necesita para prosperar.

Compartir:

Déjanos tu comentario

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *

Scroll al inicio