Workflow inseguro en GitHub Actions comprometió credenciales de Snowflake

Los investigadores de la empresa Wiz identificaron una vulnerabilidad de tipo workflow injection en el repositorio público snowflakedb/snowflake-connector-net en GitHub, que permitía a un atacante ejecutar comandos arbitrarios en el entorno del GitHub Actions runner con solo crear un Issue especialmente elaborado. Durante unas pruebas autorizadas, los investigadores extrajeron un token de API de Jira que, según sus datos, otorgaba acceso de solo lectura a proyectos internos de Snowflake, incluidas tareas de ingeniería, seguimiento de conformidad con requisitos de seguridad y bug bounty. La vulnerabilidad existió en la automatización CI/CD del repositorio durante cinco días —del 18 al 23 de junio de 2026— y se subsanó el mismo día en que se recibió el informe. No se han identificado versiones afectadas del conector para .NET.

Mecanismo de la vulnerabilidad

El problema se encontraba en el archivo .github/workflows/jira_issue.yml, que se ejecutaba al abrir un Issue público en el repositorio. El workflow contenía dos errores críticos:

• Interpolación directa de la entrada del usuario en un bloque shell: el título y el cuerpo del Issue se insertaban directamente en el bloque run:, lo que creaba un vector clásico de inyección de comandos. Un atacante podía inyectar comandos shell arbitrarios a través del texto del Issue.
• Comprobación de autorización inoperante: el workflow comprobaba el valor de github.event.pull_request.user.login, aunque el evento desencadenante era un Issue y no un Pull Request. Según la documentación de GitHub, el acceso a una propiedad inexistente del contexto devuelve una cadena vacía. Como resultado, la comparación con whitesource-for-github-com[bot] nunca funcionaba como filtro, y cualquier usuario podía activar la ejecución del workflow.

En ese mismo paso del workflow estaban disponibles los secretos JIRA_BASE_URL, JIRA_USER_EMAIL y JIRA_API_TOKEN, lo que significaba que una inyección de comandos exitosa daba automáticamente acceso a estas credenciales.

Explotación y alcance del impacto

Según Wiz, su sistema automatizado Red Agent detectó y explotó la vulnerabilidad durante unas pruebas de seguridad autorizadas. La carga útil inicial provocó un error de sintaxis en el shell, tras lo cual el sistema adaptó su enfoque. Los investigadores indican que recibieron una devolución de llamada (out-of-band callback) desde el GitHub Actions runner y extrajeron el token de API de Jira.

De acuerdo con el informe de Wiz, el token pertenecía a la cuenta [email protected] y proporcionaba acceso de solo lectura a proyectos de Jira en el dominio snowflakecomputing.atlassian.net, que abarcaban tareas de ingeniería, seguimiento de conformidad de seguridad y bug bounty. Cabe señalar que los detalles de la explotación y el alcance de los permisos obtenidos se basan exclusivamente en las declaraciones de Wiz: los registros de auditoría de Snowflake no se han divulgado públicamente.

Cronología y corrección

• 18 de junio de 2026. El workflow vulnerable se incorporó a la rama principal a través del pull request #1218 (squash merge, commit 4a1b8ce).
• 23 de junio de 2026. Wiz remitió el informe a través de HackerOne (report #3819931). Ese mismo día, Snowflake aplicó la corrección en el pull request #1402, sustituyendo la interpolación directa de expresiones de GitHub por el paso de valores mediante variables de entorno a jq.
• 24 de junio de 2026. Según Wiz, el token de Jira fue rotado.

Snowflake, en una declaración reproducida por Wiz, señaló que la investigación «no encontró indicios de acceso no autorizado». De acuerdo con Wiz, la revisión de Snowflake no descubrió usos por terceros del token durante la ventana de exposición de cinco días. No obstante, los registros de auditoría de Snowflake no se publicaron, por lo que la verificación independiente de estas afirmaciones no es posible.

Cuestión de atribución: el papel de GitHub Copilot

Wiz describió la vulnerabilidad como el resultado de un cambio introducido por GitHub Copilot Autofix. Sin embargo, el análisis del historial de commits en el repositorio dibuja un panorama más complejo. El commit 6d0e2fa, marcado explícitamente como coautoría de Copilot Autofix, modificaba el archivo jira_close.yml, y no el vulnerable jira_issue.yml. El refactorizado inseguro de jira_issue.yml figura en un commit independiente 094038e, atribuido por GitHub al desarrollador sfc-gh-hpathak. Ambos cambios se incorporaron al squash merge final 4a1b8ce, donde Copilot Autofix figura entre los coautores. De este modo, la participación de Copilot en el pull request queda acreditada, pero no la autoría de las líneas de código concretamente vulnerables.

Problema sistémico y recomendaciones

Este incidente es un ejemplo típico de una clase de vulnerabilidades documentada por GitHub ya en julio de 2025: la interpolación directa de datos no confiables procedentes de eventos (título del Issue, cuerpo, comentarios) en bloques run: de GitHub Actions. El enfoque recomendado es el uso de variables de entorno intermedias, que es precisamente lo que se implementó en la corrección de Snowflake.

Las organizaciones que utilizan GitHub Actions en repositorios públicos deben:

• Realizar una auditoría de todos los archivos de workflow para detectar interpolaciones directas de expresiones ${{ github.event.* }} dentro de bloques run:. Cualquier dato procedente de Issues, Pull Requests o comentarios debe pasarse a través de variables de entorno.
• Verificar las condiciones de filtrado en los workflows: asegurarse de que las comprobaciones de autorización hacen referencia a propiedades que existen en el contexto del evento desencadenante real. La discrepancia entre el tipo de evento y la propiedad verificada conduce a la evasión del filtro.
• Minimizar el ámbito de los secretos: no pasar credenciales a pasos que procesan entradas de usuario. Separar los pasos de validación de los datos de entrada y los pasos que utilizan secretos.
• Implantar un escaneo automatizado de los archivos de workflow —por ejemplo, con herramientas como actionlint— para detectar patrones de interpolación inseguros en la fase de revisión de código.

Este caso demuestra que, incluso en ausencia de una vulnerabilidad en el propio producto de software, la compromisión de la infraestructura CI/CD de un repositorio público puede desembocar en la filtración de credenciales internas con acceso a sistemas corporativos. La ventana de exposición de cinco días y la corrección rápida el mismo día del informe son un ejemplo positivo de respuesta, pero el mero hecho de que código inseguro llegara a la rama principal indica la necesidad de reforzar las comprobaciones de seguridad de los workflows en la fase de merge. Las organizaciones con repositorios públicos en GitHub deberían revisar de inmediato sus configuraciones de Actions para detectar patrones similares de interpolación directa de datos procedentes de eventos.