Una comilla, un fallo de código y una clave válida de Jira: así se explotó la vulnerabilidad de Snowflake en tres pasos

Un agente de IA que busca vulnerabilidades detectó por sí mismo un error en el repositorio público de Snowflake y, a través de él, accedió al sistema interno de Jira de la empresa. La vulnerabilidad apareció apenas cinco días antes, y cuando GitHub Copilot revisó el código, no detectó la sección peligrosa.

Especialistas de Wiz detectaron el problema con la herramienta autónoma Red Agent, que comprobaba los repositorios de Snowflake en GitHub. El error estaba en un script de GitHub Actions del proyecto snowflakedb/snowflake-connector-net. Cualquier usuario de GitHub podía ejecutar el proceso vulnerable simplemente creando una nueva incidencia con un título preparado.

El código problemático apareció el 18 de junio de 2026 después de que se aceptara la solicitud de cambio nº 1218. Antes, el título de la incidencia se colocaba primero en una variable de entorno y luego se pasaba de forma segura al programa jq para formar los datos. La nueva versión insertaba directamente el contenido del título en el comando de shell. Bastaba añadir una comilla simple para salir de la cadena esperada y forzar al servidor a ejecutar un comando ajeno.

Wiz prestó especial atención al papel de GitHub Copilot. El registro final del cambio indica "Copilot Autofix powered by AI" como coautor, y cuando Copilot revisó las modificaciones, las consideró seguras y no detectó el error crítico. Wiz aclara que no se puede afirmar con certeza que el fragmento vulnerable lo escribiera la inteligencia artificial.

La protección adicional, que debía impedir que el script se ejecutara sin restricciones, tampoco funcionó. Cuando un usuario creaba una incidencia normal, uno de los campos verificados siempre quedaba vacío, por lo que la condición se cumplía automáticamente para cualquier usuario de GitHub. Como resultado, la barrera de protección no detenía a nadie.

Red Agent no se limitó a encontrar el error. El agente preparó de forma autónoma una solicitud de prueba e intentó obtener credenciales de Jira desde el entorno de GitHub Actions. Primero obtuvo un error de sintaxis. El sistema analizó la respuesta, modificó el comando y lo volvió a probar. En unos segundos Wiz obtuvo datos que permitían acceder a la instancia interna de Jira de Snowflake con la cuenta qa@snowflake.net.

La clave obtenida daba permisos de lectura sobre proyectos de Snowflake relacionados con cómo la empresa desarrolla productos, cumple requisitos de seguridad y recompensa las vulnerabilidades encontradas. Así, el error en el repositorio público abría acceso a información interna de la empresa.

Wiz informó a Snowflake del problema el 23 de junio. La empresa corrigió el script ese mismo día, restaurando el modo seguro anterior de procesar los datos, y el 24 de junio reemplazó la clave de Jira. Al revisar los registros, los especialistas comprobaron que, durante los cinco días que la vulnerabilidad existió, terceros no la explotaron. Snowflake declaró que no hay indicios de acceso no autorizado.

Wiz recomienda comprobar los cambios creados u aprobados por estos sistemas con la misma rigurosidad que el código escrito por una persona.