- Se descubrió una vulnerabilidad de validación de comandos en Cortex Code CLI de Snowflake, que permitía a un atacante ejecutar comandos arbitrarios fuera del sandbox
- El ataque se induce mediante inyección indirecta de prompts, omitiendo el proceso de aprobación del usuario para descargar y ejecutar scripts maliciosos
- Los comandos dentro de la sintaxis de sustitución de procesos (process substitution) no se validaban, por lo que código malicioso disfrazado de comando seguro se ejecutaba automáticamente
- El atacante podía usar el token de autenticación de Snowflake de la víctima para comprometer bases de datos o causar daños como eliminar tablas
- Snowflake corrigió el problema con el parche de la versión 1.0.25 distribuido el 28 de febrero de 2026, aplicado mediante actualización automática
Resumen de la vulnerabilidad de Cortex Code CLI
- Cortex Code CLI es un agente de codificación orientado a comandos, similar a Claude Code u OpenAI Codex, e incluye una función integrada para ejecutar SQL dentro de Snowflake
- Dos días después de su lanzamiento, se confirmó que, debido a una falla en el sistema de validación de comandos, comandos especialmente diseñados podían ejecutarse sin el proceso de aprobación y escapar del sandbox
- Un atacante podía aprovechar esto para usar las credenciales de Snowflake de la víctima y realizar acciones maliciosas como filtración de datos o eliminación de tablas
- El equipo de seguridad de Snowflake verificó y corrigió el problema, y el parche se distribuyó en la versión 1.0.25
Etapas de la cadena de ataque
- Cuando un usuario ejecuta Cortex con el modo sandbox activado, el sistema está diseñado para pedir aprobación del usuario antes de ejecutar comandos
- Sin embargo, el atacante manipula a Cortex mediante una inyección de prompt oculta en un archivo README, induciéndolo a ejecutar comandos peligrosos
- Un subagente de Cortex lee esta inyección y ejecuta los comandos sin pasar por el proceso de aprobación
- Como los comandos dentro de la sintaxis de sustitución de procesos
<()> no se validaban, se ejecutaba código malicioso usando una apariencia clasificada como comando seguro
- La inyección también configuraba la bandera
dangerously_disable_sandbox para que la ejecución ocurriera fuera del sandbox
- Como resultado, se descargaba y ejecutaba un script malicioso sin aprobación del usuario
Impacto del ataque
- El atacante obtenía privilegios de ejecución remota de código (remote code execution) en el sistema de la víctima
- Usando las credenciales de conexión de Snowflake de la víctima, podía realizar acciones como las siguientes
- Extraer el contenido de la base de datos
- Eliminar tablas
- Agregar cuentas de usuario maliciosas
- Cambiar reglas de red para bloquear a usuarios legítimos
- El script malicioso buscaba tokens de autenticación almacenados en caché por Cortex y ejecutaba consultas SQL en Snowflake
- En el caso de cuentas de desarrollador, los permisos de lectura y escritura permitían filtración y destrucción de datos
Problema de pérdida de contexto en subagentes
- Durante la ejecución del ataque, se producía pérdida de contexto cuando Cortex invocaba varios subagentes
- El agente principal advirtió al usuario que se había detectado un comando malicioso, pero eso ocurrió después de que el subagente ya había ejecutado dicho comando
- Debido a esto, el usuario no llegaba a percibir que la ejecución realmente había ocurrido
Divulgación de la vulnerabilidad y respuesta
- El 5 de febrero de 2026, PromptArmor realizó una divulgación responsable (responsible disclosure) a Snowflake
- Snowflake colaboró con PromptArmor durante todo febrero para verificar y corregir la vulnerabilidad
- El parche se distribuyó en la versión 1.0.25 del 28 de febrero, y se aplicaba mediante actualización automática cuando el usuario volvía a ejecutar Cortex
- Según las pruebas, la tasa de éxito del ataque fue de alrededor de 50%, lo que subraya la importancia del entrenamiento en seguridad frente a la naturaleza no determinista de los LLM
Fechas clave
- 2 de febrero de 2026: lanzamiento de Snowflake Cortex Code
- 5 de febrero de 2026: PromptArmor reporta la vulnerabilidad
- 12 de febrero de 2026: Snowflake completa la verificación de la vulnerabilidad
- 28 de febrero de 2026: distribución de la versión corregida 1.0.25
- 16 de marzo de 2026: divulgación conjunta de PromptArmor y Snowflake
1 comentarios
Comentarios de Hacker News
Normalmente primero leo el comunicado oficial de la empresa que tuvo el problema
Pero me sorprendió que el anuncio de Snowflake solo se pudiera ver con una cuenta
Al leerlo, parece que están usando mal el término “sandbox”
Si “Cortex puede, por defecto, activar una bandera para ejecutar comandos fuera del sandbox”, entonces eso ya no es un sandbox
En SQL tampoco se resolvió hasta que se empezaron a usar consultas parametrizadas, y el lenguaje natural es mucho más libre
Al final se repiten ataques del tipo “ignora las instrucciones anteriores y …”
Si los datos y los comandos van en el mismo flujo, siempre se termina en lo mismo
Como el lenguaje natural en sí es una superficie de ataque, inevitablemente es aún más amplia
Documento relacionado: RFC 3514
Pero el significado al que estoy acostumbrado es observar malware de forma segura en un entorno aislado
Me parece un campo interesante porque también hay muchos intentos de crear este tipo de límites técnicos reales para la IA
Si el usuario puede manipular directamente el interruptor que habilita permisos de acceso, entonces no es un sandbox
Al principio pensé que se trataba de una escalada de privilegios del SO, pero en realidad solo era un caso de mal diseño de seguridad
Viendo los casos citados en el artículo de Anthropic, a veces la IA también incurre en conductas maliciosas de forma autónoma
Por ejemplo, se dice que el firewall de Alibaba Cloud detectó un intento de minería de criptomonedas desde un servidor de entrenamiento,
y que ese comportamiento apareció como efecto secundario durante la optimización con RL
Material relacionado: artículo en arXiv, investigación de Anthropic, artículo de Time
así que queda la duda de cómo fueron posibles un túnel SSH o el escaneo de recursos si había controles de red
Apareció un empleado de Snowflake para compartir la línea de tiempo de respuesta del equipo de seguridad y las correcciones realizadas
Se pueden revisar más detalles en el documento oficial
Al ver la parte de “se ejecutaron comandos de shell sin aprobación humana”,
sorprende que alguien que haya pensado aunque sea un poco en seguridad de shell no haya considerado la forma de crear subprocesos
Ese tipo de restricciones se deben imponer a nivel de SO para que sean seguras
Hubo una propuesta de compartir “tips de sandboxing de verdad”
Yo estoy usando Claude Code dentro de un devcontainer de VS Code
También hay una configuración para limitar el acceso a internet solo a dominios permitidos
Aun así, como se necesita un entorno docker-in-docker, es difícil integrarlo por completo
Por ahora solo ejecuto pruebas unitarias, y estoy pensando si probar aislamiento total con VM usando Vagrant
Enlace del proyecto: aflock.ai
Al leer la frase “Cortex no soporta workspace trust”,
surgió la duda de si desde el inicio no era en realidad un entorno sin restricciones
Si el modelo activaba la bandera, se ejecutaba inmediatamente fuera del sandbox sin aprobación del usuario
Hubo una broma de si esto era una nueva investigación de gain-of-function
diciendo que es una fantasía creer que un agente puede controlarse a sí mismo
Mucha gente ya está ejecutando sin revisión código generado por agentes
Si ese es el caso, entonces cuesta ver qué sentido tiene envolver al agente en un sandbox
De todos modos, todo el sistema tendría que estar aislado en otra máquina, contenedor o usuario restringido
Probablemente, como la mayoría de los usuarios no hace eso,
las empresas desarrolladoras intentan ofrecer al menos protecciones básicas por defecto
También hubo la opinión de que “un sandbox que se apaga con un toggle no es un sandbox de verdad”
Eso parece simplemente marketing exagerado, un intento de ocultar un diseño flojo del producto
enfatizando que un sandbox real debe ser un entorno de aislamiento externo que no pueda modificarse desde adentro