Una IA escribió el error de seguridad. Otra IA lo encontró cinco días después

El 18 de junio de 2026, llegó un parche al repositorio público Snowflake-connector-net de Snowflake, en coautoría de una herramienta llamada Copilot Autofix, la función de GitHub que propone correcciones automáticas para los hallazgos de seguridad. Según la firma de seguridad Wiz, ese parche reemplazó una forma segura de manejar la entrada con interpolación de cadenas sin formato: colocó el título de un problema de GitHub directamente en un comando de shell. Cinco días después, el sistema de prueba autónomo de Wiz, al que llama Red Agent, atravesó el agujero resultante.

Vale la pena entender la mecánica porque es muy común. El repositorio ejecutó una automatización que creaba un ticket de Jira cada vez que alguien abría un problema. El título del problema se pasó a un comando de shell y el paso de desinfección, la parte destinada a eliminar caracteres peligrosos, se ejecutó después de que la plantilla ya se había expandido. Ese orden es todo el error. Una comilla simple en el título era suficiente para salir de la cadena deseada y agregar comandos arbitrarios. Un segundo defecto lo agravó: una puerta que verificaba quién había abierto la solicitud de extracción se evaluaba como verdadera en los eventos del problema, porque en esos eventos no había ninguna solicitud de extracción.

El agente de Wiz recibió un error de sintaxis de shell en su primer intento, lo ajustó y recibió una devolución de llamada del ejecutor de automatización. Lo que recuperó fue el token API de Jira que utilizó el flujo de trabajo, una cuenta con acceso de lectura a los proyectos de ingeniería, cumplimiento de seguridad y recompensas por errores de Snowflake. Snowflake parcheó el flujo de trabajo el mismo día, rotó el token el 24 de junio y dice que su investigación no encontró evidencia de acceso no autorizado durante el período de cinco días. GitHub ha cuestionado públicamente el marco en el que Copilot Autofix escribió la falla.

Dejando de lado quién tiene la culpa, la historia sigue siendo instructiva. Los asistentes de codificación de IA son muy buenos para producir código que parece correcto y pasa la revisión, que es exactamente el perfil de cambio que más probablemente pasará desapercibido para un encargado de mantenimiento ocupado. El error aquí no es exótico; es el tipo de error de pedido que comete un humano cansado los viernes. La novedad es la velocidad en ambos extremos. Una máquina lo propuso, un humano lo aprobó en segundos porque estaba etiquetado como una solución de seguridad, y una máquina lo encontró y lo explotó en una semana. La brecha donde una persona realmente lee la diferencia se está reduciendo en ambas direcciones.

Qué significa esto para ti: si escribes código, la lección práctica es pequeña y aburrida y vale la pena hacerla de todos modos. Trate los parches sugeridos por la IA para la automatización de la creación y la implementación como un riesgo mayor que los parches al código de aplicación normal, porque esa automatización generalmente tiene credenciales reales. Nunca coloque entradas que no sean de confianza, y el título de un problema de un extraño es una entrada que no es de confianza, directamente en un comando de shell. Si no escribe código, la conclusión es acerca de las etiquetas de confianza: un cambio marcado como “corrección de seguridad” recibe menos escrutinio que cualquier otro tipo, lo que lo convierte en el lugar más atractivo para ocultar un error.

Fuentes

• Wiz: Red Agent explota la vulnerabilidad Snowflake omitida por GitHub Copilot
• The Register: Una IA rompió el código de Snowflake, luego otro agente de IA lo explotó
• The Hacker News: La falla de Snowflake GitHub Actions permite que los problemas elaborados activen la inyección de comandos
• The Next Web: GitHub cuestiona la afirmación de Wiz de que Copilot Autofix escribió la falla