El ataque de supply chain y su vector en GitHub Actions
GitHub informó sobre una cadena de ataques de supply chain que afectó a npm y GitHub Actions y se basó en un flujo de trabajo mal configurado. Estos workflows de GitHub Actions automatizan procesos continuos de integración y despliegue (CI/CD), pero una configuración incorrecta puede permitir que código externo se ejecute con permisos elevados.
En el caso de AsyncAPI, el fallo se produjo en un workflow con la opción pull_request_target activada, usada para ejecutar tareas cuando se abre un pull request. Esta configuración ejecutaba código del pull request del atacante con acceso a tokens y secretos, en lugar de tomar solo código de la rama base segura.
Este error expuso el Personal Access Token (PAT) del bot asyncapi-bot, lo que permitió a los atacantes enviar cambios directamente a ramas usadas para publicar los paquetes. Así se dieron pasos automatizados clave sin control adecuado, facilitando la intrusión.
Estas fallas derivan en la ejecución de código arbitrario no autorizado dentro de procesos de confianza, que deberían funcionar como barreras para evitar la manipulación maliciosa. Se trata de un tipo de ataque conocido como 'pwn request', que explota la confianza implicada en la configuración de CI/CD.
Ver los datos en tabla
| Concepto | |
|---|---|
| versiones maliciosas publicadas | 5 |
| paquetes afectados | 4 |
| pull requests abiertos al repositorio asyncapi/generator | 37 |
Fuente: GitHub
Detalles del compromiso en la organización AsyncAPI
El 14 de julio de 2026, un atacante consiguió publicar cinco versiones maliciosas en cuatro paquetes npm de AsyncAPI: @asyncapi/specs versión 6.11.2-alpha.1 y 6.11.2, @asyncapi/generator 3.3.1, @asyncapi/generator-components 0.7.1 y @asyncapi/generator-helpers 1.1.1.
Estas publicaciones se realizaron en una ventana de aproximadamente 90 minutos. La versión alpha de @asyncapi/specs se lanzó primero y fue seguida 24 minutos después por la versión estable con la misma carga maliciosa, probablemente para asegurar la diseminación del código malicioso con firmas válidas.
El código malicioso incluía un 'loader' inyectado que se ejecutaba al usar estos paquetes, una técnica para interceptar o alterar funcionalidades en tiempo de ejecución que puede facilitar la ejecución de código adicional o la captura de información sensible.
Durante el incidente había 37 pull requests abiertos en el repositorio asyncapi/generator, lo que facilita entender cómo un atacante pudo aprovechar un repositorio en alta actividad para camuflar su ataque y ejecutarlo rápidamente.
La limitación de controles avanzados de seguridad en CI/CD
Aunque GitHub Actions usa federación de identidad OIDC para mejorar la seguridad en la autenticación entre sistemas, este método no previene problemas derivados de errores de configuración que exponen tokens internos dentro de los scripts de automatización.
Además, los paquetes y artefactos se publicaron con firmas válidas de procedencia (provenance signatures), un mecanismo que verifica qué commits originaron la compilación y su integridad. Sin embargo, en este caso los commits no fueron autorizados, lo que supone una brecha en la protección ofrecida por estas firmas.
Esto significa que la protección no está solo en la adopción de tecnología, sino también en la correcta configuración y revisión diaria de pipelines, configuraciones y accesos. Un fallo en una capa puede invalidar la seguridad que se espera en otras, como demuestra este atentado.
Por último, este evento evidencia que la seguridad en la cadena de suministro debe considerar el ciclo completo, desde la gestión del código fuente y colaboraciones externas hasta el proceso de publicación final, y no solo confiar en controles aislados.
Implicaciones para la comunidad y para la gestión del riesgo
Los paquetes afectados entre @asyncapi son utilizados por desarrolladores para definir y generar especificaciones y componentes, por lo que la distribución de versiones maliciosas puede comprometer múltiples proyectos que dependen de ellos, ampliando el impacto potencial del ataque.
Este incidente pone en alerta a organizaciones que gestionan código abierto sobre la necesidad de auditar minuciosamente sus workflows en plataformas de automatización, asegurando que flujos como pull_request_target no ejecuten código de fuentes externas sin restricciones.
También resalta el desafío que supone la colaboración abierta, donde muchos contribuidores y solicitudes de cambios conviven, aumentando la superficie de ataque y la complejidad para mantener la seguridad.
Para los directivos y responsables de tecnología, el caso AsyncAPI es un recordatorio de que la protección de la cadena de suministro requiere vigilancia activa, auditorías constantes y formación técnica para evitar configuraciones inseguras que puedan ser explotadas por actores maliciosos.