Dos GitHub Actions de terceros que habían sido comprometidas en una campaña de Mini Shai-Hulud fueron reactivadas por su mantenedor y permanecieron accesibles durante más de una semana, a pesar de que seguían apuntando a código malicioso. Tras el compromiso ocurrido el 18 de mayo, el equipo de seguridad de GitHub eliminó las acciones actions-cool/issues-helper y actions-cool/maintain-one-comment, impidiendo que cualquier flujo de trabajo descendente descargara el malware.
Según investigadores de la empresa de seguridad de aplicaciones Socket, desde el 16 de septiembre y hasta el 25 de septiembre, ambas acciones volvieron a estar activas con las mismas etiquetas de versión, lo que provocó que los flujos de trabajo que hacían referencia a ellas descargaran y ejecutaran la carga útil antigua.
El ataque de cadena de suministro Mini Shai-Hulud de mayo afectó a 323 paquetes y 639 versiones de paquetes en el índice de Node Package Manager (npm), infectándolos con malware dirigido a tokens, credenciales y secretos de CI/CD de desarrolladores.
Los investigadores de Socket descubrieron que el miércoles pasado las etiquetas de versión de actions-cool/issues-helper y actions-cool/maintain-one-comment apuntaban a un commit que contenía la carga útil ofuscada dentro del archivo 'index.js'.
El 16 de septiembre de 2026, ambos repositorios volvieron a ser accesibles. Sus etiquetas de versión no se limpiaron primero. Todavía apuntan al contenido malicioso introducido el 18 de mayo, por lo que cualquier flujo de trabajo que haga referencia a cualquiera de las acciones mediante una etiqueta de versión reanudó la descarga y ejecución de la carga útil en su siguiente ejecución.
No está claro exactamente por qué estos repositorios se reactivaron sin que se realizara primero una limpieza adecuada. Socket señala que el gráfico de dependencias de GitHub enumera aproximadamente 15.000 repositorios que dependen de 'issues-helper', aunque esto no significa que todos ellos hayan sido comprometidos.
Los investigadores indican que aún no han establecido cuántos dependientes hacen referencia a cualquiera de las acciones mediante una etiqueta mutable en lugar de un commit fijado. Sin embargo, explican que las acciones afectadas son aquellas que se ejecutan casi a diario, ya que satisfacen necesidades de mantenimiento de incidencias.
El 25 de septiembre, Socket descubrió que ambas acciones habían sido deshabilitadas nuevamente en GitHub, lo que provocó que los flujos de trabajo que las referencian fallaran en lugar de ejecutar la carga útil.
Socket recomienda buscar referencias a ambas acciones, eliminarlas o fijar un commit limpio verificado, revisar las ejecuciones desde el 16 de septiembre y rotar los secretos accesibles a los flujos de trabajo que ejecutaron una etiqueta afectada. Los desarrolladores potencialmente afectados deben buscar referencias a ambas acciones y eliminarlas o fijar un commit limpio verificado. La exposición comenzó el 16 de septiembre entre las 11:09 y las 18:16 GMT+2.
Construya su plano de seguridad para ataques impulsados por IA
Únase a Mikko Hyppönen y líderes de seguridad de la NFL, CHANEL y Atlassian en una cumbre digital de dos horas sobre qué cambian los ataques a velocidad de IA, qué deberían dejar de hacer los defensores y cómo validar, decidir, corregir y revalidar a velocidad de máquina.
Artículos relacionados:
- Microsoft confirma que GitHub está caído en todo el mundo
- GitHub y PyPI añaden defensas basadas en tiempo contra ataques de cadena de suministro
- Direcciones de correo electrónico expuestas de proyectos GitLab permiten a atacantes enviar código
- Repositorios falsos de LastPass Authenticator en GitHub distribuyen el nuevo infostealer Rapuncel
- Paquetes npm maliciosos evaden las defensas de scripts de instalación en tiempo de ejecución
.jpg)
Deja una respuesta