La empresa de seguridad Wiz publicó el 17 de agosto una investigación en la que describe cómo su agente autónomo de seguridad ofensiva descubrió y explotó una vulnerabilidad de inyección de scripts en un flujo de trabajo de GitHub Actions perteneciente al repositorio público snowflakedb/snowflake-connector-net, y la usó para exfiltrar un token que concedía acceso de lectura al Jira interno de Snowflake.

La cronología es inusualmente ajustada

La vulnerabilidad salió a producción cuando se fusionó la PR #1218 el 18 de junio de 2026. Wiz la identificó, la explotó y la notificó a través de HackerOne el 23 de junio; Snowflake la parcheó ese mismo día en el commit 1dc7766, y rotó el token de Jira el 24 de junio. La exposición fue de cinco días. El token se autenticaba como qa@snowflake.net en el tenant de Atlassian de Snowflake, lo que otorgaba acceso de lectura a los proyectos de seguimiento de ingeniería, seguridad y cumplimiento, y bug bounty.

Qué falla en el encuadre habitual

La historia circula como «una IA escribió el fallo y otra IA lo explotó». Esa simetría es la parte que nadie puede respaldar. La postura de GitHub, comunicada a los periodistas, es que las contribuciones que llevaron a la vulnerabilidad fueron redactadas por un humano y no fueron revisadas ni contribuidas por Copilot. La propia publicación de Wiz añade una actualización en la que admite que no está claro si el cambio de código contó con asistencia de IA, y señala que la contribución documentada de Copilot Autofix en esa pull request fue una corrección separada a un archivo distinto. Así que la afirmación sobre la autoría es disputada por el proveedor y matizada por la investigadora; aun así, es la afirmación que está acaparando la cobertura.

El hallazgo indiscutible es el más grave

Lo que nadie discute: un agente autónomo ensambló por sí solo toda la cadena de ataque —reconocimiento, hallazgo de un flujo de trabajo inyectable, explotación, exfiltración de credenciales y movimiento lateral hacia un sistema SaaS अलग—— contra un gran proveedor de plataformas de datos. Y quienquiera que escribiera el fallo, el propio escaneo de GitHub no lo detectó antes de la fusión. Ese es un hallazgo sobre la cobertura defensiva, y no depende en absoluto de la disputa sobre la autoría.

Qué se alcanzó y qué no

Hay una tercera distorsión que conviene señalar. Se trataba del flujo de trabajo CI de un repositorio público de un conector, y el acceso obtenido fue de lectura a proyectos de Jira. No era la plataforma de datos de Snowflake, ni eran datos de clientes. Snowflake afirma que su investigación no encontró indicios de acceso no autorizado más allá de los investigadores, y que los registros de auditoría mostraron que Wiz fue el único tercero en el endpoint. «Snowflake comprometido» y «lectura de Jira mediante un runner de Actions» no son la misma frase.