Código generado por IA, exploit por IA

El 18 de junio de 2026, un commit fusionado al repositorio público de Snowflake contenía una vulnerabilidad de inyección de comandos en su propia canalización de CI/CD. El código no había sido escrito a mano — había sido generado y revisado por GitHub Copilot Autofix, la propia función de remediación automática de vulnerabilidades de GitHub, impulsada por IA generativa. Cinco días después, Wiz Red Agent, un agente de seguridad autónomo, descubrió la vulnerabilidad, la explotó y accedió a las credenciales de Jira ejecutándose en los runners de GitHub Actions.

Lo ocurrido es un hito raro en la seguridad del software: dos sistemas de IA actuando en secuencia — uno introduciendo una falla, otro encontrando y explotando la misma falla — y una de las empresas de datos más importantes del mundo como consecuencia.

La vulnerabilidad

El commit en cuestión formaba parte de un parche de seguridad aparentemente legítimo. El PR fue generado por Copilot Autofix después de que una alerta de CodeQL identificara una posible vulnerabilidad en el flujo de trabajo `jira_close.yml`, un archivo responsable de cerrar automáticamente los tickets de Jira cuando se fusionaba un pull request. Lo que hizo Autofix fue reemplazar una dependencia antigua — una acción de Atlassian Jira que dependía del repositorio `gh-actions` — por llamadas directas a la API de Jira usando curl.

El cambio parecía sensato en teoría: eliminar dependencias externas, simplificar el flujo. Pero el modelo de IA no comprendió que la nueva implementación no escapaba adecuadamente de un parámetro de entrada usado en la construcción de la URL de la solicitud. Quien fusionó el PR — probablemente un humano confiando en la recomendación — no se dio cuenta de que estaba introduciendo una vía de inyección de shell.

El problema no estaba en el código de la aplicación principal del Snowflake. Estaba en las herramientas internas de integración que la empresa usa para gestionar su propio flujo de desarrollo. Es precisamente ahí donde se escondía la falla: en flujos de trabajo que los equipos de seguridad raramente auditan porque los tratan como infraestructura interna, no como software de producción.

El descubrimiento

Wiz Red Agent es una herramienta de auditoría autónoma de Wiz Research — básicamente, un agente de IA especializado en probar la seguridad de repositorios públicos. A diferencia de los escáneres tradicionales que buscan patrones conocidos de vulnerabilidad, Red Agent está diseñado para pensar en términos de cadena de explotación: si yo fuera a atacar esta empresa, ¿por dónde entraría?

El 23 de junio, el agente analizó el repositorio público del Snowflake y percibió que el flujo de trabajo `jira_close.yml` podía manipularse a través del título de un issue abierto en GitHub. El título del issue se pasaba directamente al curl sin sanitización — y dado que GitHub expone ese valor para otros flujos de trabajo, el agente pudo inyectar comandos que se ejecutarían en el runner del CI/CD.

A partir de ahí, la explotación fue directa. Los runners de GitHub Actions se ejecutaban dentro del entorno del Snowflake y poseían variables de entorno que contenían credenciales de Jira. Al ejecutar comandos inyectados, Red Agent accedió a esas credenciales, validó el acceso al sistema interno de Jira y confirmó que podía leer datos sensibles del equipo de ingeniería.

El informe completo de la Wiz, publicado el 17 de agosto, detalla que el agente no hizo más de lo que un auditor legítimo necesitaría hacer: explorar la cadena de confianza entre GitHub Issues y el CI/CD para demostrar que un atacante real podría hacer lo mismo. Snowflake no fue responsable de la pérdida de datos en el evento — Red Agent solo leyó credenciales, no modificó nada — pero el hecho de que la vulnerabilidad existiera durante cinco días sin detección es alarmante.

Por qué importa

Este incidente revela un patrón que tiende a repetirse a medida que la adopción de IA generativa en el desarrollo de software se acelera. Herramientas como Copilot Autofix fueron diseñadas para reducir el tiempo de corrección de vulnerabilidades — GitHub afirma que el tiempo mediano de corrección cayó de 90 minutos a 28 minutos durante las pruebas beta. Es una métrica impresionante y, en muchos casos, válida para bugs triviales como variables no inicializadas o tipos incorrectos.

Pero cuando el contexto es código que interactúa con APIs externas, configura pipelines o maneja autenticación, la IA opera en el territorio más peligroso: entiende la sintaxis, pero no la intención. El modelo vio una alerta de seguridad y generó una corrección que parecía resolver el problema a nivel del código fuente. Lo que no percibió fue que la corrección creaba un vector de ataque completamente nuevo en capas que el modelo ni siquiera sabía que existían.

No es que Copilot Autofix esté fallando de forma única — es el paradigma de confianza automatizada. Cuando los desarrolladores comienzan a confiar sistemáticamente en correcciones generadas por IA, especialmente en código de infraestructura, están automatizando la introducción de vulnerabilidades a escala. La diferencia es que, esta vez, la herramienta que descubrió la falla también fue una IA.

Snowflake ya corrigió el flujo de trabajo y la Wiz divulgó el informe de forma responsable, sin exponer detalles que pudieran reproducirse. La lección es más amplia: a medida que la industria integra IA en cada etapa del ciclo de desarrollo — de la escritura al parche de vulnerabilidad —, el mismo principio de seguridad debe aplicarse: verifique el código generado por IA con el mismo rigor (o más) que verificaría cualquier contribución de terceros. El código escrito por máquina no es menos arriesgado que el código escrito por humano. Es solo arriesgado de manera diferente.

Fuentes: Wiz Blog, dev.to, TechTarget

✓ Fuentes independientes cruzadas y verificadas antes de la publicación