Copilot Autofix abrió una inyección de shell en la canalización CI/CD de Snowflake

Una corrección de seguridad escrita por Copilot Autofix de GitHub y fusionada en un repositorio de Snowflake el 18 de junio de 2026 eliminó un patrón de entrada sanitizada y dejó la canalización CI/CD de la empresa vulnerable a inyección de comandos, y cinco días después, un agente de investigación de IA autónomo encontró la brecha, la explotó y extrajo credenciales de Jira en funcionamiento de un runner de GitHub Actions, Wiz Research lo reveló el 17 de agosto de 2026.

La vulnerabilidad residía en jira_issue.yml, un flujo de trabajo de GitHub Actions en snowflakedb/snowflake-connector-net, el repositorio público del conector de datos .NET de Snowflake. El flujo se activaba cada vez que alguien abría un issue en GitHub e interpolaba el título del issue (texto totalmente controlado por la persona que lo crea) directamente en un script de shell. Como el disparador era issues: opened, cualquier cuenta de GitHub en internet podía alcanzarlo sin autenticación.

El “Red Agent” de Wiz, una herramienta autónoma de investigación de seguridad que opera a través del programa de recompensas de errores HackerOne de Snowflake, marcó el flujo de trabajo, construyó un exploit funcional y exfiltró un token de API de Jira del entorno del runner. Snowflake parcheó el flujo el mismo día que recibió el informe, el 23 de junio de 2026, rotó la credencial al día siguiente y le dijo a Wiz que sus registros de auditoría no mostraban que ningún otro actor hubiera tocado los sistemas expuestos durante la ventana de cinco días.

El “Autofix” eliminó el sanitizador

El commit que introdujo el patrón inyectable se incorporó a través de PR #1218, “SNOW-2069227: Update jira workflows”, fusionado el 18 de junio de 2026. El historial del pull request muestra a un autor humano trabajando en la automatización de Jira desde agosto de 2025 — y, a mitad del proceso, un commit coautoría de Copilot Autofix powered by AI, el bot de GitHub Advanced Security que genera correcciones sugeridas para alertas de escaneo de código.

La sugerencia de IA cambió la forma en que el flujo manejaba el título del issue. El código existente pasaba el título a través de una variable env: y construía su carga JSON con jq --arg, un patrón que mantiene el texto no confiable fuera del shell. La sustitución sugerida eliminó eso a favor de una expansión directa de cadena:

“ run: | TITLE=$(echo '${{ github.event.issue.title }}' | sed 's/"/\"/g' | sed "s/'/\'/g") “

El escape con sed se ejecuta después de que el motor de plantillas de GitHub ya ha sustituido el título en el script. Una comilla simple en el título rompe el contenedor echo '...', y todo lo que sigue se ejecuta como shell. La documentación de GitHub sobre Copilot Autofix describe la función como la generación de “una única corrección sugerida para una alerta, que usted revisa y aplica por sí mismo” — el paso de revisión es donde esta pasó.

El flujo también incluía una condición de protección que parecía restringir quién podía activarlo:

“ if: (github.event_name == 'issues' && github.event.pull_request.user.login != 'whitesource-for-github-com[bot]') “

En eventos de issue, github.event.pull_request siempre es nulo, por lo que la comparación siempre evalúa como verdadera. Cada usuario de GitHub pasó la barrera.

Un agente en cada lado del exploit

El primer intento de exfiltración de Red Agent falló. Su carga útil utilizó el carácter de comentario # para absorber el resto de la línea inyectada, pero el comentario también consumió el paréntesis de cierre de TITLE=$(...), y el runner devolvió un error de sintaxis de bash en lugar de ejecutarse. Según el informe de Wiz, el agente analizó el error, reescribió su carga para cerrar el bloque de shell con ; echo ' y lo intentó de nuevo.

La carga útil funcional, entregada como título del issue, codificó en base64 las variables de entorno JIRA_API_TOKEN, JIRA_USER_EMAIL y JIRA_BASE_URL del runner y las envió a un escuchador fuera de banda mediante curl. La respuesta llegó de un runner de GitHub Actions alojado en Azure en cuestión de segundos.

El token recuperado se autenticó como [email protected] contra snowflakecomputing.atlassian.net, con acceso de lectura a los proyectos de ingeniería, cumplimiento de seguridad y seguimiento de recompensas de errores de Snowflake.

La remediación de Snowflake, fusionada en PR #1402 el 23 de junio de 2026, restauró la segura variable env: y el patrón de análisis jq --arg. El token de Jira fue revocado y rotado el 24 de junio de 2026. Wiz afirmó que eliminó de forma segura todos los datos accedidos durante su prueba de concepto.

“Snowflake agradece a Wiz por su informe responsable y la colaboración en torno a estos hallazgos a través de nuestro programa de divulgación de vulnerabilidades y recompensas, HackerOne,” dijo la compañía en un comunicado publicado con el informe de Wiz. “La divulgación se recibió el 23 de junio de 2026, se investigó y remedió de inmediato, y nuestra investigación no encontró evidencia de acceso no autorizado.”

Lo que muestra la ventana de cinco días

La divulgación se sitúa en medio de un patrón documentado: cambios asistidos por IA que avanzan a través de la revisión más rápido que las suposiciones de seguridad sobre ellos. Los propios registros de auditoría de Snowflake son lo que hacen legible este incidente: permiten a la empresa afirmar, y a Wiz confirmar, que la ventana de exposición no produjo acceso de terceros. El análisis de los registros de auditoría de Snowflake confirmó que ninguna parte externa accedió al punto final durante la ventana de cinco días.

La cronología también comprime una secuencia que la industria ha tratado como hipotética. Un asistente de codificación eliminó un patrón defensivo que se había implementado específicamente para prevenir inyecciones de shell, porque el asistente no tenía registro de por qué existía ese patrón. Un agente ofensivo luego encontró y armó el resultado en días, autocorregiendo su exploit contra la salida de error en vivo. El lado del exploit se ejecutó sin un humano en el teclado; en el lado de la codificación, la IA generó el cambio pero un humano aplicó la sugerencia y lo fusionó — lo que es exactamente el paso de revisión que falló.

El informe de Wiz recomienda que los pull requests generados por IA pasen por el mismo análisis estático que el código humano, que los equipos acorten la vida útil de las credenciales para igualar la velocidad de descubrimiento automatizado, y que las barreras de seguridad impidan que los agentes reemplacen analizadores estructurados por interpolación directa de cadenas. Check Point movió la inspección de prompts para tráfico de IA a los firewalls empresariales a principios de este verano, y Unite.AI ha cubierto escapes de sandbox de agentes y sistemas agenticos que alcanzan objetivos de producción reales a medida que el lado ofensivo madura. El incidente de Snowflake es la misma historia contada desde dentro de una canalización CI: la vulnerabilidad estuvo activa durante cinco días, y la única razón por la que se presenta como un estudio de caso en lugar de una notificación de brecha es cuál agente llegó primero.