Un equipo de investigación de Wiz ha detallado un fallo de inyección que afectaba la automatización de GitHub Actions en un repositorio público relacionado con el conector .NET de Snowflake. La pieza central del problema no estaba en el producto, sino en cómo un workflow de CI/CD procesaba datos provenientes de un issue creado en GitHub.
Según el informe, un atacante podría haber aprovechado entradas manipuladas (por ejemplo, el título y el cuerpo de un issue) para alterar el comportamiento del paso que ejecutaba un comando en el workflow. En el proceso, el workflow expuso credenciales de Jira dentro del entorno de ejecución, lo que amplificó el impacto potencial.
Qué se descubrió en el repositorio
El problema se identificó en el archivo .github/workflows/jira_issue.yml. Este workflow se activaba cuando se abría un issue público y, en el mismo flujo de trabajo, proporcionaba a un paso del script variables con información para interactuar con Jira: JIRA_BASE_URL, JIRA_USER_EMAIL y JIRA_API_TOKEN.
Wiz señaló que la vulnerabilidad estaba acotada a la automatización de CI/CD del repositorio: no se identificó una versión de la liberación del Snowflake Connector for .NET afectada específicamente por este comportamiento.
Cómo funcionaba el fallo de inyección
La investigación explica que el workflow insertaba valores controlados por el atacante provenientes del issue directamente dentro de un bloque de ejecución tipo shell run. En términos prácticos, eso significa que el workflow terminaba ejecutando comandos en los que parte del contenido provenía de un lugar no confiable.
Además, el workflow contenía una comprobación que no encajaba con el evento que lo disparaba. Aunque el flujo se ejecutaba por la apertura de un issue, el script evaluaba github.event.pull_request.user.login, un campo perteneciente a un evento de pull request que no existe para issues.
GitHub aclaró que, cuando se intenta consultar una propiedad inexistente, el resultado se evalúa como cadena vacía. En este escenario, la comparación involucrando a un bot asociado no detuvo que un issue ordinario llegara al job vulnerable.
Explotación durante pruebas autorizadas
Wiz afirmó que su equipo aprovechó el vector durante un proceso de pruebas de seguridad autorizado. En la primera iteración del intento, el payload provocó un error de sintaxis en la shell, lo que llevó al equipo a ajustar su enfoque.
Tras ese ajuste, los investigadores reportaron que recibieron un callback fuera de banda desde el runner de GitHub Actions, lo que indicaría que el control del flujo de ejecución había sido alcanzado. Con esa señal, Wiz aseguró que obtuvo el token de la API de Jira usado por el workflow.
El token de Jira y el alcance del acceso
De acuerdo con Wiz, el token pertenecía a qa@snowflake.net. Ese token otorgaba acceso de solo lectura a proyectos de Jira utilizados para actividades vinculadas a ingeniería, cumplimiento de seguridad y seguimiento de bug bounty.
Wiz especificó además que el acceso se refería a instancias asociadas al dominio snowflakecomputing.atlassian.net. Los investigadores recalcaron que los permisos subyacentes, el historial de ejecuciones del workflow y los registros de auditoría no son públicos.
Reporte, ventana de exposición y corrección
Wiz declaró que informó el hallazgo a Snowflake a través de HackerOne el 23 de junio de 2026, bajo el reporte #3819931. Snowflake habría integrado la corrección ese mismo día mediante un pull request #1402.
El arreglo, según el resumen de Wiz, consistió en reemplazar la expansión directa de expresiones de GitHub por el uso de variables de entorno que se pasan a jq como argumentos. Con ello se evita que datos no confiables se conviertan en parte del comando de shell de forma peligrosa.
Wiz también precisó que el workflow vulnerable llegó a la rama por defecto cinco días antes, el 18 de junio, cuando se fusionó el pull request #1218. Indicaron que la versión corregida ya está reflejada en la rama master.
Qué dijo Snowflake
En una declaración reproducida por Wiz, Snowflake sostuvo que su investigación no encontró evidencia de acceso no autorizado. Wiz, por su parte, explicó que el token fue rotado el 24 de junio y que la revisión de Snowflake no halló uso externo no relacionado durante la ventana de exposición de cinco días.
Asimismo, se señaló que los registros de auditoría del sistema subyacente no se han publicado, por lo que los detalles sobre el contexto completo del token y su uso solo se conocen de forma limitada.
Relación con cambios en el historial de GitHub
Wiz describió el origen del problema como resultado de un cambio asociado a GitHub Copilot Autofix. Sin embargo, el historial disponible no demostraba que Copilot fuera el autor directo de las líneas vulnerables en jira_issue.yml.
De acuerdo con la reconstrucción del historial:
- El commit coatribuido por Copilot explícitamente (6d0e2fa) modificó jira_close.yml.
- El refactor inseguro en jira_issue.yml aparece en un commit fechado el 25 de agosto de 2025 (identificado como 094038e), atribuido por GitHub a sfc-gh-hpathak.
- Más tarde, ambos cambios se integraron en el commit de squash de 18 de junio (identificado como 4a1b8ce), que incluye a Copilot Autofix entre sus coautores.
En consecuencia, el historial confirma participación de Copilot en la solicitud de integración del PR #1218, pero no prueba que haya generado específicamente las líneas inseguras.
Advertencias previas de GitHub sobre esta clase de fallos
GitHub ya había documentado en julio de 2025 un patrón relacionado con la inyección en workflows. El aviso recomendaba no expandir datos provenientes de issues o fuentes no confiables directamente dentro de bloques de ejecución (run), y proponía el uso de variables intermedias para controlar el contenido antes de usarlo.
Este contexto ayuda a entender por qué la corrección aplicada en el repositorio buscó precisamente mover los valores a variables de entorno y procesarlos mediante una herramienta como jq en modo de argumentos, reduciendo la superficie de comando.
Estado actual y valoración de riesgo
A fecha de 17 de agosto de 2026, Wiz indicó que no se había localizado un CVE, un puntaje CVSS o una entrada en el catálogo de CISA Known Exploited Vulnerabilities (KEV) vinculada a este caso. También se mencionó que no se identificó una actualización de liberación del conector asociada a este problema.
Según la información disponible, la interpolación vulnerable ya no está presente en la rama master. Además, el material primario revisado por Wiz no estableció que el fallo se explotara de forma maliciosa en el mundo real ni que existiera una intrusión demostrada de clientes.
Qué aprender de este caso
Más allá de la solución concreta, este episodio deja una lección clara para equipos que operan con CI/CD:
- No mezclar datos no confiables (como texto de un issue) con comandos de shell sin una sanitización adecuada.
- Evitar interpolaciones directas dentro de bloques de ejecución. Mejor usar variables intermedias y herramientas que trabajen con argumentos.
- Revisar condicionales y eventos: un check que apunta a un campo inexistente puede falsear la intención de seguridad.
En entornos donde el workflow maneja credenciales —aunque sean tokens con acceso limitado— cualquier desviación en el tratamiento del input puede convertir un “problema de automatización” en un riesgo de acceso.
Conclusión
El fallo de inyección descrito por Wiz en un workflow de GitHub Actions asociado a Snowflake destaca cómo una mala práctica en la automatización puede terminar afectando credenciales de terceros como Jira. Aunque la investigación no evidenció una intrusión de clientes y Snowflake reportó no haber encontrado acceso no autorizado, la corrección aplicada refuerza una recomendación: separar input no confiable de la ejecución de comandos.
Si tu equipo mantiene pipelines similares, revisa dónde interpolas datos de issues o pull requests y confirma que las condiciones de seguridad del workflow se basen en eventos y propiedades correctas.
Fuente: https://thehackernews.com/2026/08/snowflake-github-actions-flaw-lets_0330881554.html
