Lo Que el Agente de Wiz Realmente Vulneró

Wiz construyó un agente autónomo de IA llamado Red Agent para buscar fallos explotables como lo haría un probador de penetración humano, y luego actuar según lo que encuentra. Apuntado a los repositorios públicos de GitHub de Snowflake, encontró un fallo de inyección de scripts en un archivo de flujo de trabajo de GitHub Actions llamado jira_issue.yml dentro de snowflakedb/snowflake-connector-net, el conector .NET de código abierto de Snowflake. El fallo permitía a cualquiera abrir un issue de GitHub con un título manipulado y hacer que la propia automatización de Snowflake ejecutara parte de ese título como un comando de shell, sin necesidad de iniciar sesión.

El primer intento de Red Agent fracasó. El runner devolvió un error de sintaxis en lugar de ejecutar el payload. En vez de detenerse ahí, el agente leyó el error, reescribió por su cuenta el título manipulado del issue y lo intentó de nuevo. El segundo intento rompió la cadena de shell y alcanzó un dominio controlado por el atacante, exfiltrando en el proceso un token de la API de Jira codificado en base64. El descubrimiento, el ajuste, la explotación y la verificación del acceso resultante ocurrieron todos en una sola sesión, sin que ningún humano decidiera el siguiente paso.

El token robado era válido y estaba autenticado como una cuenta de servicio de Snowflake, lo que otorgaba acceso de lectura a una instancia interna de Jira que cubría proyectos de ingeniería, cumplimiento de seguridad y seguimiento de recompensas por errores. El código vulnerable llevaba activo desde que se fusionó el PR #1218 el 18 de junio de 2026, que reemplazó un patrón de análisis seguro por interpolación directa de variables en un comando de shell. Snowflake lo parcheó el 23 de junio de 2026, restaurando el patrón seguro, y revocó y renovó el token expuesto; una auditoría de los registros no encontró evidencia de que ninguna parte externa lo hubiera usado durante la ventana de exposición de cinco días.

Wiz Nombró a Copilot Coautor del Fallo

El informe original de Wiz señaló el commit que introdujo el fallo y observó que GitHub Copilot Autofix aparecía como coautor en él. El relato se escribió solo: un asistente de programación con IA parecía haber ayudado a escribir el mismo fallo que un agente de seguridad con IA luego encontró y explotó de forma autónoma, en ambos extremos.

La línea de coautoría era real, y las fusiones squash hacen que ese tipo de evidencia parezca más sólida de lo que es. Un pull request puede contener muchos commits individuales de muchos colaboradores, pero una fusión squash los reúne todos en un único commit en la rama principal, y cada línea de coautoría de cada uno de esos commits viaja con él hasta el resultado combinado. Un nombre en esa línea registra participación en algún punto del pull request, no autoría de una línea específica. Para cuando Wiz actualizó su publicación el 17 de agosto de 2026, su propio lenguaje ya se había suavizado hasta reconocer que no estaba claro si Copilot había contribuido siquiera a las líneas vulnerables.

El Historial de Commits de GitHub Dice Que lo Escribió un Humano

GitHub realizó su propia revisión interna del mismo repositorio y llegó a una conclusión distinta. Según GitHub, un ingeniero humano de Snowflake escribió la refactorización insegura, en un commit separado fechado el 25 de agosto de 2025, unos diez meses antes de que se fusionara el pull request vulnerable, y Copilot Autofix ni revisó ni contribuyó a esas líneas concretas.

El commit real de coautoría de Copilot dentro del pull request #1218 modificó un archivo distinto, jira_close.yml, sin relación con las líneas vulnerables de jira_issue.yml que explotó Red Agent. Cuando el pull request se fusionó en un único commit squash, la línea de coautoría de Copilot viajó con él de todos modos, adherida a un cambio que nunca había tocado.

La disputa está ahora en público con dos relatos incompatibles y sin árbitro independiente. Wiz señala una línea de coautoría en el historial de commits vivo; GitHub señala una revisión interna del mismo repositorio que interpreta la autoría de otra manera. Nadie fuera de las dos empresas tiene el acceso necesario para determinar cuál lectura es correcta.

La Brecha de Gobernanza Que Todo Equipo con IA Debería Notar

Ejecutar un asistente de programación con IA y un escáner de seguridad con IA en el mismo pipeline se está convirtiendo rápidamente en la configuración predeterminada, no en la excepción. Cuando algo falla bajo esa configuración, tanto la parte que encuentra el fallo como la herramienta acusada de haberlo escrito pueden ser sistemas de IA, y la única prueba a la que cualquiera de las partes puede recurrir es el historial de commits de un repositorio. Ese historial es tan confiable como las prácticas que lo produjeron, y una fusión squash rutinaria acaba de demostrar que puede adherir el nombre de un colaborador al error de otro sin que nadie lo pretendiera.

El fallo en sí permaneció expuesto cinco días y necesitó cinco días más para parchearse. La discusión sobre quién lo escribió duró más que la propia vulnerabilidad, y ocurrió entre dos proveedores con los recursos y el acceso al repositorio para investigarlo como corresponde. Una empresa con menos disciplina para preservar el historial de commits de sus propios archivos de flujo de trabajo, y sin una respuesta establecida sobre quién dentro de la empresa está autorizado a publicar una afirmación de autoría antes de que se convierta en una disputa pública, no resolverá su versión con tanta limpieza.

Leer a continuación: Una participación valía más que los tres fondos  |  Un modelo frontera retirado vuelve a estar en línea