Dos GitHub Actions comprometidas volvieron a estar disponibles el 16 de septiembre de 2026 con sus etiquetas apuntando al mismo código malicioso, según una investigación de Socket actualizada el 25. Las acciones actions-cool/issues-helper y actions-cool/maintain-one-comment fueron deshabilitadas de nuevo el 25 de septiembre. Una empresa colombiana que las usó por etiqueta durante esa ventana debe revisar ejecuciones y secretos accesibles al workflow: que ahora falle la descarga no borra lo que pudo ejecutarse antes.

Servicios de Insylux relacionados: Para convertir este análisis en acciones verificables, consulte Ethical Hacking y Security GAP Assessment. Cada servicio tiene un alcance distinto y debe seleccionarse según activos, riesgo y resultado esperado.

GitHub Actions y Mini Shai-Hulud: qué ocurrió

Socket documenta que las dos acciones habían sido comprometidas en mayo y deshabilitadas por GitHub. Cuando volvieron a estar accesibles el 16 de septiembre, sus etiquetas de versión seguían resolviendo a contenido malicioso. Los workflows que las invocaban por una etiqueta mutable podían descargar y ejecutar ese código en su siguiente corrida. La actualización del 25 registra que ambas fueron deshabilitadas de nuevo. El incidente es una regresión de contención, no una nueva versión legítima de las acciones.

El gráfico de dependencias de GitHub citado por Socket muestra alrededor de 15.000 repositorios dependientes de issues-helper. Eso no significa 15.000 compromisos: no se conoce cuántos usaban etiquetas vulnerables, cuántos ejecutaron un workflow durante la ventana ni qué secretos estaban disponibles. Separar dependientes, ejecuciones y exposición de credenciales es esencial para no convertir un indicador de alcance potencial en una cifra de víctimas.

Por qué una etiqueta puede reactivar código antiguo

Una referencia como uses: actions-cool/issues-helper@v2.2.1 apunta a una etiqueta, no a un contenido inmutable. El runner resuelve esa referencia al preparar cada job y descarga el paquete correspondiente. Si la etiqueta sigue en un commit malicioso y el repositorio vuelve a estar disponible, la siguiente ejecución puede cargarlo sin que el proyecto consumidor haya modificado una línea de su propio código. Socket observó ese cambio en historiales de workflows que pasaron de fallar al inicio a ejecutarse durante varios minutos.

Fijar una acción a un SHA completo de un commit verificado reduce el riesgo de cambios de etiqueta, pero no vuelve seguro un SHA malicioso. El equipo debe revisar procedencia, contenido y permisos de la acción antes de adoptarla. También debe distinguir una acción de mantenimiento de issues de una dependencia de compilación: la primera puede parecer poco crítica, pero se ejecuta dentro de la infraestructura de CI y accede a lo que el job le entrega.

Qué pudo quedar expuesto en el pipeline

Un workflow dispone de un GITHUB_TOKEN con permisos definidos para el job y puede recibir secretos explícitos, credenciales de nube, tokens de publicación o datos de despliegue. No todas las ejecuciones tienen el mismo acceso. Un workflow activado al abrir un issue puede tener permisos distintos de uno que publica un paquete; la evaluación debe mirar el YAML y el evento de cada repositorio. La acción maliciosa no obtiene automáticamente todos los secretos de toda la organización.

Socket describe una carga orientada a recolectar credenciales y secretos de los pipelines que la ejecutaron. Si una organización encuentra una corrida durante la ventana, trate los secretos efectivamente accesibles como candidatos a rotación y busque uso posterior. No publique valores en un ticket ni los copie a un informe sin protección. La prioridad de revocación depende de alcance: un token de despliegue de producción exige respuesta distinta de un token de lectura de un repositorio de prueba.

Cómo localizar referencias afectadas

Busque en los archivos .github/workflows/ de todos los repositorios que administra la empresa las dos acciones por su nombre exacto. Registre referencia completa, rama, evento disparador, permisos del token, secretos entregados y último uso. Incluya repositorios archivados que todavía ejecutan trabajos programados, proyectos de proveedores y plantillas compartidas que generan nuevos workflows. Una búsqueda en el repositorio principal no cubre necesariamente filiales o equipos separados.

Después examine el historial de ejecuciones entre el 16 y el 25 de septiembre. Una referencia afectada que no llegó a ejecutarse presenta un riesgo diferente de una corrida completada. Una referencia fijada a un SHA limpio anterior al compromiso tampoco tiene el mismo estado que una etiqueta mutable. Socket señala que no conoce la proporción exacta de dependientes en cada categoría; la organización puede conocer la suya con inventario y logs.

Acciones inmediatas sin romper despliegues

Retire las referencias a esas acciones o reemplácelas por una alternativa verificada y de permisos mínimos. No fije la etiqueta comprometida a su SHA actual. Conserve el YAML, los registros de jobs y la lista de secretos accesibles antes de limpiar. Suspenda temporalmente workflows de alto impacto si hay indicios de ejecución maliciosa, pero coordine la medida con los dueños de despliegue para no perder capacidad de recuperación o parches urgentes.

Rote credenciales en orden de impacto y revóquelas donde sea posible. Una rotación incompleta deja activo el token anterior; una rotación impulsiva puede dejar servicios indisponibles. Compruebe repositorios, releases, paquetes y entornos de nube para detectar acciones posteriores no autorizadas. Si hay indicios de abuso, preserve evidencia con el equipo de Análisis Forense Digital antes de eliminar registros útiles.

Reduzca lo que una acción de terceros puede hacer

Defina permisos explícitos y mínimos para GITHUB_TOKEN por workflow y job. Una acción que etiqueta issues no debería tener capacidades de publicar paquetes o modificar código si no las necesita. Separe secretos de producción de trabajos disparados por eventos públicos y exija aprobaciones para entornos sensibles. Revise si el trabajo puede ejecutarse sin secretos, con credenciales temporales o con una identidad federada limitada.

Un atacante puede beneficiarse incluso de permisos que parecen secundarios si permiten leer metadatos, crear comentarios con enlaces o modificar artefactos usados aguas abajo. Por ello la revisión sigue la cadena completa: quién dispara el job, qué descarga, qué ejecuta, qué permisos recibe y qué resultado consumen otros sistemas. Una regla de aprobación de dependencias debe tratar a las acciones como código ejecutable, no como simples líneas de configuración.

Qué significa para equipos de desarrollo en Colombia

La investigación de Socket no identifica víctimas colombianas. La relevancia es técnica y empresarial para cualquier compañía local cuyos repositorios usaran esas acciones. Una consultora de software, fintech o comercio con pipelines de despliegue debe responder si la dependencia estuvo presente, si se ejecutó y qué credenciales se expusieron. No hace falta atribuir una filtración local para justificar una revisión acotada y urgente.

El responsable de seguridad y desarrollo puede presentar a dirección una matriz de repositorios afectados, ejecución observada, permisos, secretos y cierre. Un servicio de Ethical Hacking autorizado puede evaluar rutas de abuso en el ciclo de desarrollo, mientras un Security GAP Assessment puede formalizar gobierno de dependencias y evidencias. La respuesta inmediata a una corrida comprometida sigue siendo investigación y revocación de credenciales.

La cadena de suministro incluye a los integradores

Una empresa puede no usar GitHub Actions en su cuenta principal y aun así recibir artefactos construidos por un proveedor que sí las utiliza. Pregunte a equipos y terceros por referencias, ventana de ejecución, secretos accesibles y acciones de contención. No exija una afirmación imposible de «riesgo cero»; pida evidencia delimitada por repositorios y fechas. El contrato debería prever avisos de componentes comprometidos y un canal para coordinar rotación de claves compartidas.

Si el proveedor conserva permisos de despliegue sobre producción, la evaluación no termina con su propio CI. Verifique qué identidades llegan al entorno del cliente y cómo se revocan. Una llave de publicación o token de registro de contenedores puede tener efectos más allá del repositorio que lo usó. La responsabilidad técnica se comparte mediante inventario y evidencias, no con un correo genérico de tranquilidad.

Un control estructural para próximos incidentes

Cree un catálogo de acciones externas con dueño, versión fijada, SHA revisado, permisos, evento y fecha de próxima revisión. Automatice una alerta cuando se agregue una nueva acción o se cambie su referencia. Pruebe que el equipo puede localizar en horas todas las ejecuciones de una dependencia concreta. Conserve logs el tiempo necesario para investigar una reactivación que se descubra días después.

Ensaye un escenario de proveedor comprometido: suspender un workflow, preservar logs, identificar secretos y revocarlos sin detener todas las entregas. El ejercicio debe mostrar qué trabajos críticos dependen de una acción pequeña de mantenimiento. No se trata de prohibir el software de terceros, sino de hacer explícito su nivel de confianza y limitar el daño si esa confianza falla.

Evidencia necesaria para declarar cerrado el caso

El expediente de cada repositorio debe indicar si alguna referencia a las dos acciones existió, si usaba etiqueta o SHA, cuántos jobs se ejecutaron en la ventana y qué permisos efectivos tenían. Adjunte identificación de las corridas, no secretos ni copias de datos sensibles. Para las ejecuciones relevantes, registre investigación de acceso posterior, credenciales rotadas, revocación comprobada y dueño que acepta el cierre. Una respuesta negativa debe basarse en búsqueda completa de workflows, no en memoria del equipo.

El área de plataforma debería comparar los permisos declarados en el YAML con el acceso real a entornos y secretos. Algunas credenciales se inyectan por configuraciones compartidas o por proveedores de despliegue que no aparecen en un archivo individual. Consulte quién puede modificar etiquetas, entornos y políticas del repositorio. Si no se conservan logs suficientes, el cierre debe expresar incertidumbre y aplicar una rotación proporcionada al riesgo. No se puede reconstruir una ejecución simplemente porque hoy la acción vuelve a estar deshabilitada.

Una revisión final del artefacto publicado o desplegado ayuda a detectar modificaciones que persistieron después de la corrida. Compruebe hashes, firmas, release notes y destinatarios de distribución cuando existan. El objetivo no es repetir todas las compilaciones por defecto, sino delimitar cuáles se generaron con una dependencia comprometida y qué controles de integridad permiten confiar en el resultado.

Preguntas frecuentes

¿Todos los 15.000 repositorios fueron comprometidos?

No. La cifra es de dependientes aproximados de una acción; Socket no determinó cuántos usaron etiquetas afectadas ni cuántos ejecutaron la carga.

¿Las acciones siguen ejecutándose ahora?

Socket actualizó el 25 de septiembre que ambos repositorios estaban deshabilitados de nuevo. El riesgo histórico de ejecuciones durante la ventana debe investigarse.

¿Basta con fijar cualquier SHA?

No. Debe verificarse que el commit es limpio y limitar permisos y secretos del workflow que lo ejecuta.

Audite la dependencia antes de la próxima entrega

Fuente y límites

La investigación sustenta el mecanismo y la cronología. No ofrece una lista de empresas colombianas comprometidas; cada organización debe revisar sus ejecuciones.