En abril de 2025, Grafana Labs reveló un incidente de seguridad significativo que afectó sus GitHub Actions, una herramienta vital para la integración continua y la entrega continua (CI/CD) en proyectos de software. Un usuario no autorizado aprovechó vulnerabilidades en uno de los flujos de trabajo automatizados dentro de un repositorio público para acceder a secretos y datos sensibles, elevando las preocupaciones sobre la seguridad en entornos DevOps y la gestión de credenciales en plataformas de código abierto. El núcleo del problema se centró en un flujo de trabajo llamado pr-patch-check-event.yml, configurado para activarse con el evento pull_request_target. Este tipo de activador es especialmente peligroso cuando se usa en repositorios públicos, debido a la manera en que GitHub maneja los permisos y secretos en los pull requests provenientes de forks externos.
A diferencia del evento pull_request tradicional, pull_request_target ejecuta el flujo de trabajo con privilegios del repositorio base, incluyendo acceso a los secretos cifrados definidos en la configuración del repositorio, aún cuando la contribución provenga de un fork no confiable. En este caso, las credenciales comprometidas fueron las asociadas a la aplicación GitHub Delivery Bot de Grafana Labs, identificadas como GRAFANA_DELIVERY_BOT_APP_ID y GRAFANA_DELIVERY_BOT_APP_PEM. Estos secretos permitieron generar tokens con permisos para modificar otros repositorios del ecosistema Grafana, abriendo la puerta para acciones maliciosas posteriores. La vulnerabilidad explotada se identifica como "Pwn Request" y se potencia debido a una falla en la sanitización de entradas controladas por un atacante, en concreto el nombre de la rama del pull request. Por medio de un script de inyección, el usuario malicioso pudo escapar del contexto literal previsto y ejecutar comandos JavaScript arbitrarios en el runner de GitHub Actions durante la primera ejecución del flujo de trabajo.
Este ataque no requirió fusión previa ni escalamiento adicional de privilegios, lo que demuestra la gravedad del riesgo. La inyección de scripts dentro de flujos de trabajo es una problemática recurrente en la seguridad de CI/CD, donde `interpolaciones` inseguras de variables públicas, tales como títulos de pull requests o nombres de ramas, sin la debida validación, pueden comprometer la integridad de todo el pipeline. En el caso de Grafana, el exploit permitió la exfiltración de los secretos primarios accedidos, con lo que el atacante pudo persistir y expandir su control. Tras obtener acceso al token legítimo del bot, el atacante inyectó un nuevo flujo de trabajo malicioso denominado "hrgqavynjp" dentro del repositorio principal. Este flujo estaba diseñado específicamente para serializar todos los secretos accesibles al entorno de ejecución, cifrarlos mediante AES-256-CBC, y posteriormente proteger la clave de cifrado con una clave RSA pública codificada.
Finalmente, los datos cifrados eran subidos como artefactos de GitHub Actions, facilitando al atacante la extracción clandestina de información crítica. Los signos visibles de esta actividad incluyeron la creación de la rama temporal por la cuenta del bot de entrega y su posterior eliminación, una técnica común para cubrir rastros y evitar detección temprana. Sin embargo, la estrategia de monitoreo y alertas de Grafana logró detectar estas anomalías casi en tiempo real, activando protocolos de respuesta rápida. Ante este escenario, Grafana Labs optó por deshabilitar GitHub Actions en todos sus repositorios públicos y emprendió una exhaustiva auditoría interna, revisión de tokens, rotación de secretos y validación que no se hubiesen accedido sistemas o datos de producción. Este incidente es una llamada de atención para la comunidad de desarrollo, especialmente para proyectos públicos que utilizan flujos de trabajo automatizados en entornos colaborativos abiertos.
La configuración insegura del evento pull_request_target y la falta de sanitización adecuada de inputs representan vectores de ataque recurrentes que pueden derivar en compromisos críticos. Para evitar episodios similares, es fundamental revisar y modificar las políticas de activación de los flujos, privilegiando el uso de triggers más seguros como pull_request o workflow_dispatch. Cuando es imprescindible usar pull_request_target, se debe restringir estrictamente el ámbito de los secretos accesibles y ejecutar dichos workflows en runners aislados sin acceso a credenciales sensibles de producción. Auditar y mantener una lista actualizada de todos los secretos utilizados en workflows es otra práctica imprescindible. Esto implica rotar claves periódicamente, eliminar secretos innecesarios y controlar minuciosamente su uso y acceso.
La implementación de secretos a nivel de entorno con revisiones obligatorias que requieran aprobación antes de ser desbloqueados aporta un nivel adicional de seguridad y supervisión. La incorporación de herramientas de monitoreo en tiempo real, como Harden-Runner de StepSecurity, puede complementar las defensas tradicionales. Estas soluciones analizan la actividad de red, la manipulación de archivos y los procesos en ejecución durante los trabajos, detectando patrones anómalos en la exportación masiva de secretos o intentos de comunicación con destinos no autorizados, facilitando una respuesta temprana a incidentes. Limitar los permisos asignados a las aplicaciones GitHub App es otra medida crítica. Aun cuando un token se vea comprometido, mantenerlo con el mínimo nivel de privilegio necesario reduce drásticamente el alcance del daño potencial.
Es recomendable revisar y ajustar estos permisos de forma recurrente según la evolución funcional de la aplicación. Finalmente, habilitar la opción que requiere aprobación manual para la ejecución de workflows provenientes de forks públicos es una defensa simple pero eficaz para prevenir que código no revisado acceda a recursos sensible durante la integración continua. En conclusión, el incidente en Grafana Labs subraya el riesgo que implica la automatización sin una seguridad robusta en los pipelines de CI/CD, especialmente en proyectos abiertos. La combinación del uso imprudente de triggers poderosos y la ausencia de sanitización adecuada creó la ventana para el ataque que pudo derivar en una fuga grave de secretos. Las mejores prácticas en la configuración y gestión de GitHub Actions, junto con la adopción de herramientas modernas de monitoreo y control de acceso, constituyen pilares fundamentales para garantizar la integridad y seguridad del desarrollo de software moderno.
Como ecosistema, aprender de incidentes como este es vital para fortalecer la confianza y resiliencia en la cadena de suministro de software.
![Tic Tac Toe Rubik's Cube / Sticker Mod [video]](/images/5048A9D2-E60A-4516-AC8F-DD148D594882)
