- O Terrarium é um ambiente de testes Python baseado no Pyodide e implantável no Cloud Run, projetado para executar código não confiável com baixo custo e latência aceitável.
- O ambiente oferece compartimentalização baseada em invocação, suporte para múltiplas bibliotecas científicas e manipulação de arquivos de entrada e saída por meio de um sistema de arquivos virtual.
- Sua arquitetura combina WebAssembly, Node.js, Docker e Cloud Run para isolar o código, mas foram detectados problemas de estabilidade e gerenciamento da integridade do serviço.
- A vulnerabilidade crítica CVE-2026-5752 permite a execução de código com privilégios de root, sem nenhuma correção planejada, portanto, recomenda-se avaliar medidas de mitigação e alternativas.
Quando falamos em executar código Python não confiável ou gerado por IA , um dos maiores desafios é como fazê-lo de forma segura , rápida e sem gastar uma fortuna em infraestrutura. Foi nesse contexto que surgiu o Terrarium, uma solução da Cohere AI projetada como um ambiente de teste para hospedar e executar esse tipo de código em contêineres implantados na nuvem, especialmente no Google Cloud Run.
Essa abordagem permitiu que desenvolvedores e empresas aproveitassem o Terrarium como um ambiente isolado para implantar código de usuário ou modelos LLM a um custo razoável e com desempenho satisfatório. No entanto, com o tempo, vulnerabilidades muito sérias também vieram à tona , incluindo uma com identificador CVE que expõe falhas críticas na segurança do sandbox e colocou o Terrarium sob os holofotes.
O que é um terrário e para que foi criado?
O Terrarium é essencialmente um ambiente de execução isolado para Python , projetado para funcionar como um contêiner Docker implantável , por exemplo, no Google Cloud Run. Seu principal objetivo é fornecer um ambiente isolado onde códigos potencialmente perigosos ou desconhecidos (como scripts enviados por usuários ou trechos de código gerados pela linguagem) possam ser implantados sem colocar a infraestrutura principal em risco.
A filosofia por trás do projeto centra-se em fornecer um serviço acessível e de baixa latência, fácil de integrar em fluxos de trabalho existentes. O Terrarium foi projetado para ser chamado via requisições HTTP, enviando o código Python a ser executado — e, opcionalmente, arquivos de entrada — e recebendo de volta os resultados da execução juntamente com os arquivos gerados.
Na prática, isso significa que um sistema externo, uma API ou mesmo uma ferramenta interna pode delegar a execução de código Python ao Terrarium , mantendo esse código em um ambiente relativamente restrito, com regras claras sobre recursos, tempo de execução e capacidades permitidas.
Uma das principais características de design do Terrarium é sua dependência do Pyodide, um compilador de CPython para WebAssembly executado dentro de um processo Node.js. Essa abordagem significa que o código Python não é executado nativamente no sistema hospedeiro, mas sim dentro de um interpretador encapsulado, teoricamente fortalecendo seu isolamento.
Desempenho, custos e principais características do ambiente de testes (sandbox).
Um dos maiores atrativos do Terrarium era a combinação de baixos custos operacionais e desempenho aceitável . Em implantações reais no Google Cloud Run, com uma configuração típica de 2 GB de memória, 1 vCPU e pelo menos uma instância sempre ativa com escalonamento automático sob demanda, o custo mensal relatado foi de cerca de US$ 30 durante as fases internas de anotação.
Em termos de velocidade, os testes descritos mostram que o Terrarium pode gerar, por exemplo, uma imagem PNG de 200 dpi de um gráfico simples do matplotlib em cerca de 900 ms de tempo de execução, ou uma versão SVG em aproximadamente 500 ms. Esses tempos referem-se ao código hospedado no Cloud Run, incluindo o ciclo de invocação típico do serviço.
Além do desempenho, o Terrarium oferecia compartimentalização completa entre as invocações . Após cada chamada, o ambiente isolado era completamente reciclado: o sistema de arquivos virtual do Pyodide, as variáveis globais, as bibliotecas carregadas e qualquer estado interno eram descartados. O objetivo era impedir que qualquer invocação herdasse dados ou contexto de uma execução anterior, reduzindo assim o risco de vazamento de informações.
Outro ponto importante é que, embora o objetivo fosse um isolamento robusto, a Cohere deixou claro que não oferecia garantias absolutas quanto à integridade do sandbox . Isso já indicava que, apesar das camadas de proteção, havia a possibilidade de vulnerabilidades serem descobertas, especialmente em um ambiente tão complexo quanto o WebAssembly e sua integração com o Node.js.
O Terrarium foi projetado para ser facilmente consumido por outros serviços: basta enviar uma solicitação HTTP para o endpoint implantado no Cloud Run, juntamente com o código a ser executado e um token de autorização (se exigido pela configuração). Em resposta, você recebe um arquivo JSON com os resultados e, se aplicável, os arquivos gerados codificados em base64.
Execução de arquivos e suporte a bibliotecas no Pyodide
Uma das características atraentes do Terrarium era sua capacidade de trabalhar nativamente com arquivos de entrada e saída . A API permitia que vários arquivos de qualquer tipo fossem anexados junto com o código Python na requisição; esses arquivos eram colocados no sistema de arquivos virtual que o Pyodide expõe ao interpretador Python.
Durante a execução, o código Python podia ler e manipular esses arquivos como se estivessem localmente dentro do ambiente isolado (sandbox). Assim que a execução fosse concluída, o Terrarium coletaria todos os arquivos criados ou modificados e os retornaria na resposta ao cliente, geralmente codificados para transferência perfeita via HTTP.
Em relação ao ecossistema de bibliotecas, por ser baseado no Pyodide, o Terrarium herdou um conjunto bastante extenso de pacotes científicos e de análise de dados . Os pacotes diretamente suportados incluem: numpy, pandas, matplotlib, sympy, beautifulsoup4, python-sat, scikit-learn, scipy e sqlite3 (este último não está habilitado por padrão, mas há a opção de carregá-lo, se necessário).
No caso específico do matplotlib, havia algumas limitações: plt.show() não era suportado neste ambiente, mas o uso de plt.savefig() para gerar imagens funcionava corretamente, desde que parâmetros excessivos não fossem forçados, como resoluções extremamente altas que aumentariam o uso de recursos.
Esse conjunto de bibliotecas tornou o Terrarium especialmente útil para tarefas como análise de dados, visualização, prototipagem de modelos de aprendizado de máquina e manipulação de informações estruturadas, tudo executado dentro de um ambiente controlado teoricamente.
Arquitetura interna: camadas de isolamento e implantação
A arquitetura do Terrarium é construída em várias camadas, projetadas para reduzir a superfície de ataque e isolar o código não confiável o máximo possível . A primeira camada é o próprio processo Node.js, que atua como host e carrega o Pyodide, ou seja, CPython compilado para WebAssembly.
O código Python enviado pelo usuário é analisado, compilado e executado no ambiente WebAssembly , e não nativamente no sistema host. Essa abordagem limita inerentemente o que o código pode fazer, já que o Pyodide usa um sistema de arquivos virtual na memória, não tem acesso direto ao disco do host e não possui recursos tradicionais de processamento em segundo plano.
Entre as restrições mais relevantes estão: nenhum acesso ao sistema de arquivos real (apenas ao sistema de arquivos virtual interno do Pyodide), ausência completa de threads e multiprocessamento, impossibilidade de iniciar subprocessos, nenhum acesso à memória do host que executa o Node.js, nenhuma possibilidade de compartilhamento de estado entre chamadas (já que todo o ambiente é reiniciado) e, por definição, nenhum acesso à rede ou à internet . Esta última limitação foi intencional como uma decisão de projeto que poderia ser revisada no futuro, mas inicialmente adicionou mais uma camada de complexidade.
A segunda camada de isolamento é a própria implantação na nuvem: o processo Node.js é executado dentro de um contêiner Docker , que é implantado no Google Cloud Run. Isso não apenas limita o tempo de execução e os recursos disponíveis, mas também desacopla o contêiner que executa o código de qualquer outra parte da infraestrutura da organização, no caso de uma hipotética violação do sandbox.
Em resumo, o projeto original do Terrarium se baseia em uma combinação de WebAssembly, Docker e Cloud Run para construir um ambiente relativamente seguro para a execução de Python, com barreiras sucessivas que dificultam a fuga do ambiente isolado para o sistema host e a rede interna.
Implantação local, implantação com Docker e implantação com o Google Cloud Run.
Para usar o Terrarium em um ambiente de desenvolvimento, era necessário ter o Node.js instalado na máquina . Uma vez atendido esse requisito, o procedimento usual consistia em instalar as dependências do projeto e executar o servidor local, juntamente com a função que lida com as solicitações de execução de código.
Com o servidor em execução, era possível enviar requisições ao endpoint local para executar arquivos de teste e scripts Python , permitindo que os desenvolvedores validassem o comportamento do ambiente de teste antes da implantação em produção. Scripts estavam disponíveis para executar um conjunto de testes em todos os arquivos .py em um diretório de teste, simplificando a verificação do ambiente.
Em ambientes conteinerizados, o Terrarium pode ser criado como uma imagem Docker e executado como um contêiner independente . As instruções típicas incluem etapas de criação, execução e parada, bem como comandos para localizar o identificador do contêiner em execução e gerenciá-lo manualmente, se necessário.
Quando o Terrarium migrou para o Google Cloud Run, ele foi implantado como um serviço HTTP com escalonamento automático e parâmetros configuráveis de recursos e concorrência. Era recomendável ajustar esses valores para equilibrar desempenho, custo e segurança . Por exemplo, para cargas de trabalho intensivas, mais CPU e memória poderiam ser alocadas, e a concorrência por instância poderia ser limitada para evitar bloqueios.
É importante notar que o Pyodide, quando configurado para o Terrarium, é executado no processo principal do Node.js. Isso significa que, se o seu código Python consumir muitos recursos ou entrar em loops complexos, ele poderá bloquear a capacidade do Node.js de responder a outras solicitações. O Pyodide sugere o uso de Workers para cenários em que seja necessário interromper ou isolar ainda mais as execuções, mas essa abordagem complica a integração e, em alguns casos, limita o suporte a bibliotecas como o matplotlib.
Gestão dos serviços de saúde e questões de estabilidade
Em implantações no Google Cloud Run, um dos desafios práticos era monitorar a integridade do serviço e se recuperar de falhas . O Cloud Run, por padrão, não oferece suporte direto a verificações de integridade definidas em Dockerfiles usando HEALTHCHECK, portanto, um pequeno ajuste adicional foi necessário.
O procedimento usual envolvia descrever o serviço Cloud Run com o gcloud e exportar a configuração para um arquivo service.yaml. Dentro desse arquivo YAML, era adicionada uma configuração livenessProbe, associada à imagem do contêiner, para que o Cloud Run pudesse detectar quando o serviço parasse de responder corretamente.
Após a modificação da configuração, o serviço existente foi substituído pelo comando gcloud apropriado, para que o Cloud Run monitorasse ativamente o status do contêiner e o reiniciasse caso a verificação em tempo real falhasse. Essa operação foi necessária apenas na primeira vez que um novo serviço foi implantado com essa imagem específica.
No nível do Docker puro, existe uma limitação adicional: o próprio mecanismo do Docker não oferece reinicializações automáticas baseadas apenas no HEALTHCHECK . Além disso, o processo com PID 1 no contêiner é particularmente protegido e não é tão fácil de encerrar internamente. Portanto, em alguns ambientes, considera-se o uso de ferramentas de terceiros, como o docker-autoheal, que monitoram a integridade do contêiner e forçam reinicializações quando problemas são detectados.
Em relação à estabilidade de execução, a equipe observou que erros como "RangeError: Maximum call stack size exceeded" apareciam frequentemente no Pyodide ao lidar com cargas de trabalho particularmente pesadas. Isso era mais comum ao usar valores de dpi muito altos na geração de PNG com matplotlib ou ao executar operações pandas particularmente complexas, sugerindo limitações internas no gerenciamento de pilha dentro do ambiente WebAssembly.
Vulnerabilidade crítica CVE-2026-5752 no Terrarium
Ao longo do tempo, foi descoberta uma vulnerabilidade crítica no Terrarium , identificada como CVE-2026-5752 e classificada com 9,3 na escala CVSS. Esse nível de gravidade indica uma falha com um impacto potencialmente muito alto na segurança dos sistemas que utilizam esse ambiente de teste.
A vulnerabilidade permite que um atacante execute código arbitrário com privilégios de root no processo hospedeiro . O vetor de ataque se baseia na travessia maliciosa da cadeia de protótipos dentro do ambiente WebAssembly do Pyodide, contornando efetivamente as restrições do sandbox.
O aspecto mais preocupante é que a exploração dessa vulnerabilidade não requer privilégios especiais nem interação adicional do usuário . Um atacante capaz de injetar código no ambiente de teste (por exemplo, explorando a funcionalidade de execução de código em uma ferramenta que utiliza o Terrarium) pode se aproveitar dessa falha para escapar do ambiente controlado.
Uma vez explorada, a vulnerabilidade poderia permitir o acesso não autorizado a arquivos de sistema sensíveis , como /etc/passwd ou outros recursos internos do contêiner , e até mesmo possibilitar a escalada de privilégios para o host ou outros serviços que compartilham a mesma infraestrutura, dependendo da configuração geral de segurança.
Essa situação representa um risco significativo para todas as organizações que utilizam o Terrarium como ambiente de execução de código de usuário ou modelo de IA . Não se trata apenas de uma vulnerabilidade teórica, mas de um cenário em que uma violação do sandbox pode levar à exposição de dados, comprometimento de serviços internos e movimentação lateral dentro da rede.
Impacto nas empresas, nos desenvolvedores e nos usuários finais
A descoberta dessa vulnerabilidade afeta diretamente qualquer empresa ou desenvolvedor que tenha integrado o Terrarium à sua infraestrutura para executar código Python não confiável . Ferramentas de desenvolvimento colaborativo, plataformas de aprendizado, serviços de análise sob demanda ou produtos de assistência de código baseados em IA podem ficar expostos se utilizarem o Terrarium como camada de execução.
Do ponto de vista do usuário final, o risco não é apenas a possibilidade de a infraestrutura do provedor de serviços ser comprometida, mas também o vazamento ou a manipulação, sem aviso prévio , de informações pessoais ou profissionais armazenadas nessas plataformas, caso um invasor consiga explorar a vulnerabilidade.
A situação se complica ainda mais pelo fato de o Terrarium não receber mais manutenção ativa . Isso significa que não se espera um patch oficial para corrigir o problema, deixando as organizações que continuam a depender dessa solução com uma vulnerabilidade conhecida e sem suporte.
Nesse contexto, continuar usando o Terrarium sem medidas adicionais representa um risco de segurança considerável . Os atacantes que conhecem a vulnerabilidade podem visar especificamente serviços que continuam usando essa tecnologia, buscando fragilidades na segurança geral do sistema.
Além disso, em ambientes onde vários serviços compartilham a mesma rede interna ou até mesmo o mesmo cluster de contêineres, um vazamento do Terrarium poderia abrir caminho para movimentação lateral em outros sistemas aparentemente isolados , amplificando o impacto potencial de um ataque bem-sucedido.
Estratégias de mitigação e alternativas a considerar.
Dada a magnitude dessa vulnerabilidade e a falta de manutenção ativa, a primeira recomendação para as organizações é avaliar urgentemente o uso atual do Terrarium . Se ele estiver sendo usado para executar código de terceiros ou código gerado por modelos de IA, a exposição é maior e exige ação imediata.
As medidas de curto prazo incluem a desativação temporária de recursos que permitem a execução de código arbitrário em produção, enquanto uma alternativa mais segura é avaliada. Outras opções incluem o fortalecimento das políticas de rede, a segmentação adicional dos serviços que utilizam o Terrarium e a restrição do acesso ao contêiner por outros sistemas.
A médio prazo, pode ser mais sensato migrar para outras soluções de sandbox ou execução isolada que tenham manutenção ativa e uma comunidade ou provedor por trás para corrigir vulnerabilidades. Isso pode envolver serviços gerenciados, ambientes de execução sem servidor com restrições mais rigorosas ou arquiteturas de microsserviços projetadas especificamente com segurança por padrão.
Em todo caso, este incidente destaca a importância de integrar boas práticas de segurança ao ciclo de vida de desenvolvimento : auditorias regulares de dependências, revisão de componentes de terceiros utilizados na arquitetura, monitoramento de CVEs relevantes e planos de resposta rápida quando uma falha crítica for detectada.
Empresas que desenvolvem ferramentas baseadas em IA que permitem aos usuários finais executar ou gerar código devem analisar cuidadosamente o design de seus ambientes de teste (sandboxes) , garantir que os processos de isolamento sejam mantidos atualizados e evitar depender de projetos abandonados para funções tão sensíveis quanto a execução de código não confiável.
Tudo no Terrarium reflete a necessidade de uma abordagem de segurança extrema para a execução de código de usuário e modelos LLM . Um ambiente de teste (sandbox) de alto desempenho e baixo custo pode parecer muito atraente, mas se uma vulnerabilidade crítica surgir sem nenhuma correção à vista, o equilíbrio é rompido e o risco se torna inaceitável para muitos casos de uso sérios.
