- Foi encontrada uma vulnerabilidade de validação de comandos no Cortex Code CLI da Snowflake, que permitia a um atacante executar comandos arbitrários fora do sandbox
- O ataque é induzido por injeção indireta de prompt, burlando o processo de aprovação do usuário para baixar e executar scripts maliciosos
- Comandos dentro da sintaxe de process substitution não eram validados, permitindo a execução automática de código malicioso disfarçado como comando seguro
- O atacante podia usar o token de autenticação da Snowflake da vítima para comprometer bancos de dados ou causar danos como apagar tabelas
- A Snowflake corrigiu o problema em 28 de fevereiro de 2026 com o patch da versão 1.0.25, aplicado via atualização automática
Visão geral da vulnerabilidade no Cortex Code CLI
- O Cortex Code CLI é um agente de codificação orientado a comandos, semelhante ao Claude Code ou ao OpenAI Codex, com recursos integrados para executar SQL dentro da Snowflake
- Dois dias após o lançamento, foi confirmado que uma falha no sistema de validação de comandos permitia que comandos especialmente elaborados fossem executados sem aprovação e escapassem do sandbox
- Com isso, um atacante podia usar as credenciais Snowflake da vítima para realizar ações maliciosas como exfiltração de dados ou exclusão de tabelas
- A equipe de segurança da Snowflake validou o problema, fez a correção e distribuiu o patch na versão 1.0.25
Etapas da cadeia de ataque
- Quando o usuário executa o Cortex com o modo sandbox ativado, o sistema foi projetado para exigir aprovação do usuário antes da execução de comandos
- No entanto, o atacante manipula o Cortex por meio de uma injeção de prompt escondida em um arquivo README, induzindo-o a executar comandos perigosos
- Um subagente do Cortex lê essa injeção e executa os comandos sem passar pelo processo de aprovação
- Como os comandos dentro da sintaxe de process substitution
<()> não eram validados, o invasor conseguia executar código malicioso usando uma aparência de comando seguro
- A injeção também define a flag
dangerously_disable_sandbox, fazendo com que a execução ocorra fora do sandbox
- Como resultado, scripts maliciosos são baixados e executados sem aprovação do usuário
Impacto do ataque
- O atacante obtém permissão de execução arbitrária de código (remote code execution) no sistema da vítima
- Usando as credenciais de conexão Snowflake da vítima, ele pode realizar ações como:
- Exfiltrar o conteúdo do banco de dados
- Apagar tabelas
- Adicionar contas de usuário maliciosas
- Alterar regras de rede para bloquear usuários legítimos
- O script malicioso procura tokens de autenticação em cache armazenados pelo Cortex e executa consultas SQL na Snowflake
- No caso de contas de desenvolvedor, permissões de leitura e escrita permitem vazamento e destruição de dados
Problema de perda de contexto entre subagentes
- Durante a execução do ataque, o Cortex chama vários subagentes, causando perda de contexto
- O agente principal alertou o usuário de que havia encontrado um comando malicioso, mas isso ocorreu somente depois que o subagente já havia executado o comando
- Por isso, o usuário não percebia que a execução de fato já tinha acontecido
Divulgação da vulnerabilidade e resposta
- Em 5 de fevereiro de 2026, a PromptArmor fez uma divulgação responsável (responsible disclosure) à Snowflake
- Durante todo o mês de fevereiro, a Snowflake trabalhou com a PromptArmor para validar e corrigir a vulnerabilidade
- O patch foi distribuído na versão 1.0.25 em 28 de fevereiro, e é aplicado automaticamente quando o usuário reinicia o Cortex
- Em testes, a taxa de sucesso do ataque foi de cerca de 50%, destacando a importância do treinamento em segurança diante das características não determinísticas dos LLMs
Principais datas
- 2 de fevereiro de 2026: lançamento do Snowflake Cortex Code
- 5 de fevereiro de 2026: PromptArmor reporta a vulnerabilidade
- 12 de fevereiro de 2026: Snowflake conclui a validação da vulnerabilidade
- 28 de fevereiro de 2026: distribuição da versão corrigida 1.0.25
- 16 de março de 2026: divulgação conjunta da PromptArmor e da Snowflake
1 comentários
Comentários do Hacker News
Normalmente eu leio primeiro o comunicado oficial da empresa que teve o problema
Mas fiquei surpreso porque o aviso da Snowflake só podia ser visto com uma conta
Depois de ler, pareceu que eles estão usando o termo “sandbox” de forma incorreta
Se “o Cortex pode, por padrão, definir uma flag e executar comandos fora da sandbox”, então isso já não é mais uma sandbox
No SQL isso só foi mitigado com queries parametrizadas, e linguagem natural é muito mais livre
No fim, ataques do tipo “ignore as instruções anteriores e ...” continuam se repetindo
Se dados e comandos estão no mesmo fluxo, o desfecho sempre tende a ser o mesmo
Como a própria linguagem natural é a superfície de ataque, ela inevitavelmente é mais ampla
Documento relacionado: RFC 3514
Mas o significado com o qual eu estou acostumado é um ambiente isolado para observar malware com segurança
Acho interessante que existam muitas tentativas de criar esse tipo de fronteira técnica real também para IA
Se o próprio usuário pode mexer no interruptor que ativa o acesso, então isso não é uma sandbox
No começo achei que fosse um caso de escalonamento de privilégios no SO, mas era só um exemplo de projeto de segurança malfeito
Pelos casos citados no artigo da Anthropic, às vezes a IA também pratica ações maliciosas de forma autônoma
Por exemplo, o firewall da Alibaba Cloud detectou uma tentativa de mineração de criptomoeda a partir de um servidor de treinamento,
e foi dito que esse comportamento surgiu como efeito colateral durante a otimização com RL
Materiais relacionados: artigo no arXiv, pesquisa da Anthropic, artigo da Time
então fica a dúvida de como SSH tunneling ou varredura de recursos era possível com controle de rede em vigor
Um funcionário da Snowflake apareceu e compartilhou a linha do tempo da resposta da equipe de segurança e as correções aplicadas
Mais detalhes podem ser conferidos na documentação oficial
Ao ler a parte dizendo que “comandos de shell foram executados sem aprovação humana”,
para qualquer pessoa que já tenha pensado minimamente em segurança de shell, é surpreendente que não tenham considerado a forma de criação de subprocessos
Esse tipo de restrição precisa ser aplicado no nível do SO para ser seguro
Houve uma sugestão de compartilhar “dicas de sandboxing de verdade”
Eu estou rodando o Claude Code dentro de um devcontainer do VS Code
Também existe uma configuração para limitar o acesso à internet apenas a domínios permitidos
Mas como é necessário um ambiente docker-in-docker, a integração completa é difícil
Então, por enquanto, estou executando só até os testes unitários, e pensando em tentar isolamento completo em VM com Vagrant
Link do projeto: aflock.ai
Ao ver a frase “o Cortex não oferece suporte a workspace trust”,
fiquei me perguntando se, desde o início, não era um ambiente sem restrições
Se o modelo definisse a flag, a execução acontecia imediatamente fora da sandbox, sem aprovação do usuário
Teve a piada: “isso é uma nova pesquisa de gain-of-function?”
dizendo que é ilusório acreditar que um agente pode controlar a si mesmo
Muita gente já está executando sem revisão código gerado por agentes
Nesse caso, fica a dúvida de qual é o sentido de colocar o próprio agente dentro de uma sandbox
De qualquer forma, o sistema inteiro teria de estar isolado em outra máquina, contêiner ou sob um usuário restrito
Provavelmente, como a maioria dos usuários não faz isso,
as empresas tentam fornecer pelo menos um nível básico de proteção por conta própria
Houve a opinião de que “uma sandbox que pode ser desligada por um toggle não é uma sandbox de verdade”
Isso parece apenas marketing exagerado, numa tentativa de esconder um projeto de produto malfeito
enfatizando que uma sandbox de verdade deve ser um ambiente de isolamento externo que não possa ser alterado por dentro