Descubrimiento de la vulnerabilidad
Investigadores de ciberseguridad de Wiz han revelado una vulnerabilidad de inyección en el flujo de trabajo de GitHub Actions del repositorio público snowflakedb/snowflake-connector-net de Snowflake. Esta vulnerabilidad permite que un problema (issue) manipulado en GitHub ejecute comandos en un flujo de trabajo que contiene credenciales internas de Jira.
La falla se encuentra en el archivo `.github/workflows/jira_issue.yml`. Este archivo se ejecuta cuando se abre un problema público y expone las variables JIRA_BASE_URL, JIRA_USER_EMAIL y JIRA_API_TOKEN en el mismo paso del flujo de trabajo. Aunque la debilidad se limitó a la automatización CI/CD del repositorio, no se identificó ninguna versión afectada del conector de Snowflake para .NET.
Detalles técnicos de la vulnerabilidad
El flujo de trabajo vulnerado insertaba directamente valores de título y cuerpo de los problemas controlados por el atacante en un bloque `run:` de la shell. Además, se verificaba la propiedad `github.event.pull_request.user.login`, a pesar de que el evento era un problema, lo que significa que la propiedad de la solicitud de extracción referenciada no existía. GitHub aclara que "si se intenta desreferenciar una propiedad inexistente, se evaluará como una cadena vacía". En este caso, la comparación contra `whitesource-for-github-com[bot]` no impidió que un problema ordinario llegara al trabajo programado.
Wiz informó que su sistema Red Agent explotó la inyección durante pruebas de seguridad autorizadas. Después de que el primer payload resultó en un error de sintaxis de shell, el sistema cambió su enfoque. Posteriormente, recibieron un callback no relacionado del ejecutor de GitHub Actions y obtuvieron el token de API de Jira usado por el flujo de trabajo. Este token, según Wiz, pertenecía a qa@snowflake.net y permitía acceso de lectura a proyectos de Jira relacionados con ingeniería, cumplimiento de seguridad y seguimiento de recompensas de errores en snowflakecomputing.atlassian.net.
Respuesta de Snowflake
Snowflake reportó que no había evidencia de acceso no autorizado tras investigar el incidente. Wiz informó que el token de Jira fue rotado el 24 de junio y la revisión de Snowflake no encontró uso externo no relacionado durante el periodo de exposición de cinco días. Los registros de auditoría subyacentes de Snowflake no han sido hechos públicos.
La vulnerabilidad fue atribuida a un cambio realizado por GitHub Copilot Autofix, aunque la historia de GitHub no establece a Copilot como autor del código vulnerable en jira_issue.yml. El commit explícito coautor de Copilot, 6d0e2fa, modificó jira_close.yml, mientras que la refactorización insegura de jira_issue.yml aparece en un commit separado del 25 de agosto de 2025, 094038e, atribuido a sfc-gh-hpathak. Ambos cambios se integraron posteriormente en el commit de squash del 18 de junio, 4a1b8ce, que lista a Copilot Autofix entre sus coautores.
Prevención y recomendaciones
GitHub documentó este tipo de inyección de flujo de trabajo en julio de 2025, advirtiendo sobre la expansión de datos no confiables de problemas directamente dentro de bloques `run:` y recomendando el uso de variables de entorno intermedias. Hasta la fecha, no se ha encontrado ninguna entrada de CVE, puntuación CVSS, ni registro en el catálogo de CISA Known Exploited Vulnerabilities (KEV) relacionado con este problema, y no se ha identificado ninguna actualización de lanzamiento del conector vinculada al mismo. La interpolación vulnerable ya no está presente en la rama maestra, y el material disponible no establece la explotación maliciosa en el entorno o compromiso del cliente.