A falha no Claude Cowork revela um dos cenários mais preocupantes da atual geração de agentes de Inteligência Artificial executados localmente: mesmo quando uma aplicação utiliza uma máquina virtual (VM) para isolar tarefas potencialmente perigosas, um erro na arquitetura de compartilhamento de arquivos pode transformar esse ambiente isolado em uma porta de entrada para o sistema hospedeiro.
A vulnerabilidade, batizada de SharedRoot, demonstrou que um agente de IA poderia escapar das restrições esperadas da VM Linux utilizada pelo Claude Cowork para macOS, obtendo acesso aos arquivos do computador do usuário. Segundo os pesquisadores responsáveis pela descoberta, aproximadamente 500 mil usuários poderiam ser afetados antes da correção, tornando o incidente um importante alerta para desenvolvedores, pesquisadores de segurança e qualquer pessoa interessada na execução local de agentes inteligentes.
Mais do que um simples bug, o caso evidencia um problema arquitetural. O incidente mostra que o isolamento de uma máquina virtual não depende apenas do hipervisor ou do sistema operacional convidado. Também depende da forma como recursos do computador hospedeiro são compartilhados com essa VM. Quando esse compartilhamento é excessivamente permissivo, uma vulnerabilidade adicional no sistema convidado pode ser suficiente para comprometer completamente a segurança do ambiente.
Como funciona a arquitetura do Claude Cowork e onde residia a falha
O Claude Cowork foi desenvolvido para permitir que agentes de IA executassem tarefas locais de maneira relativamente segura. Para isso, a aplicação utilizava o Apple Virtualization Framework, criando uma máquina virtual Linux responsável pela execução das operações solicitadas pelo usuário.
Em teoria, essa arquitetura oferece um bom nível de isolamento. O agente trabalha dentro da VM e qualquer comportamento inesperado deveria permanecer restrito ao sistema operacional convidado.
Entretanto, a descoberta da vulnerabilidade SharedRoot mostrou que a separação entre a VM e o macOS não era tão rígida quanto parecia.
O compartilhamento excessivo do diretório raiz
O elemento central da vulnerabilidade estava no funcionamento do daemon coworkd.
Em vez de compartilhar apenas diretórios específicos necessários para o funcionamento do aplicativo, o serviço montava todo o diretório raiz ( / ) do macOS hospedeiro dentro da máquina virtual Linux utilizando VirtioFS.
Esse diretório aparecia na VM em /mnt/.virtiofs-root, permitindo que praticamente toda a estrutura de arquivos do computador estivesse disponível para acesso pelo ambiente convidado.
Na prática, a VM não estava completamente isolada.
Ela possuía uma visão praticamente completa do sistema de arquivos do Mac.
Essa decisão arquitetural simplificava determinadas operações do agente de IA, mas também aumentava drasticamente a superfície de ataque caso algum invasor conseguisse elevar privilégios dentro da máquina virtual.
Da VM ao Mac: o acesso sem restrições
Enquanto o agente permanecesse executando com permissões limitadas, o risco era relativamente controlado.
O problema surgia quando um atacante obtinha privilégios administrativos (root) dentro da VM Linux.
Nesse momento, o acesso ao diretório compartilhado deixava de ser apenas leitura de arquivos específicos e passava a permitir operações muito mais amplas sobre os dados do usuário.
Entre os arquivos potencialmente acessíveis estavam:
- Chaves SSH
- Credenciais armazenadas
- Tokens de autenticação
- Projetos de desenvolvimento
- Repositórios Git
- Documentos pessoais
- Arquivos de configuração
- Histórico de comandos
- Segredos utilizados por ferramentas DevOps
Em outras palavras, o isolamento proporcionado pela virtualização deixava de cumprir seu principal objetivo.
Como a falha no Claude Cowork dependia de uma segunda vulnerabilidade
É importante destacar que a SharedRoot não era, sozinha, um mecanismo completo de invasão.
Ela precisava ser combinada com uma vulnerabilidade capaz de fornecer privilégios elevados dentro da VM Linux.
Foi exatamente isso que ocorreu com o uso do exploit conhecido como pedit COW.
A cadeia de ataque consistia em duas etapas:
- Explorar uma falha no kernel Linux da máquina virtual.
- Utilizar os privilégios obtidos para acessar o diretório raiz compartilhado do macOS.
Essa combinação transformava um problema aparentemente restrito ao sistema convidado em um comprometimento direto do computador hospedeiro.
O vetor de ataque: explorando o kernel Linux no sistema convidado
O segundo componente da cadeia era o exploit conhecido como pedit COW, associado à CVE-2026-46331.
A vulnerabilidade afetava o subsistema act_pedit, responsável por operações de modificação de pacotes dentro do mecanismo de controle de tráfego (Traffic Control) do kernel Linux.
Embora seja um componente pouco conhecido fora da comunidade de desenvolvimento do kernel, sua exploração permitia uma escalada de privilégios bastante significativa.
Os pesquisadores demonstraram que, explorando inadequadamente estruturas internas do kernel, um usuário sem privilégios poderia executar código com permissões de root dentro da máquina virtual.
Outro fator importante foi a disponibilidade dos namespaces de usuário e dos namespaces de rede, recursos que permaneciam habilitados na VM.
Esses mecanismos são extremamente úteis para contêineres e ambientes isolados, mas também aumentam as possibilidades de exploração quando combinados com vulnerabilidades do kernel.
Após obter acesso privilegiado, o atacante passava a interagir livremente com o sistema de arquivos compartilhado pelo VirtioFS, rompendo, na prática, a barreira entre a VM Linux e o macOS.
Embora tecnicamente não se trate de um “escape” clássico do hipervisor, o resultado final era bastante semelhante: dados do hospedeiro tornavam-se acessíveis por meio de um ambiente que deveria permanecer isolado.
Por que essa vulnerabilidade chama tanta atenção
Casos envolvendo escapes de máquinas virtuais costumam exigir falhas complexas no hipervisor.
O caso da SharedRoot é diferente.
O hipervisor da Apple permaneceu íntegro.
O problema estava na política de compartilhamento adotada pelo aplicativo.
Isso torna o incidente particularmente relevante porque demonstra que uma arquitetura insegura pode comprometer toda a proteção oferecida pela virtualização, mesmo sem existir uma falha direta no mecanismo responsável por executar a VM.
Em outras palavras, não basta criar uma máquina virtual.
É necessário definir cuidadosamente quais recursos poderão ser compartilhados entre os dois sistemas.
Mitigações, posicionamento da Anthropic e lições para a segurança em IA
Após a divulgação responsável da vulnerabilidade, a Anthropic adotou medidas para reduzir significativamente o risco.
Entre as mudanças está a priorização da execução em nuvem como padrão para determinados fluxos de trabalho, reduzindo a dependência da execução local de agentes altamente privilegiados.
Além disso, especialistas ressaltam que aplicações desse tipo devem seguir princípios rígidos de isolamento.
Os pesquisadores da Accomplish AI, responsáveis pela divulgação técnica, destacam diversas recomendações importantes para ambientes semelhantes.
Entre elas estão:
- Compartilhar apenas diretórios estritamente necessários.
- Utilizar montagens somente leitura sempre que possível.
- Restringir ou desabilitar user namespaces quando não forem indispensáveis.
- Limitar network namespaces em ambientes controlados.
- Aplicar políticas rigorosas de seccomp para reduzir chamadas de sistema disponíveis.
- Adotar o princípio do menor privilégio em todos os componentes da arquitetura.
- Evitar que processos dentro da VM tenham acesso desnecessário ao sistema de arquivos do hospedeiro.
Essas práticas reduzem significativamente a possibilidade de uma falha em cadeia comprometer todo o ambiente.
O que essa descoberta representa para o futuro dos agentes de IA
A popularização dos agentes autônomos de IA está mudando a forma como aplicações interagem com computadores pessoais.
Esses sistemas já conseguem modificar arquivos, executar comandos, utilizar ferramentas de desenvolvimento, acessar navegadores e automatizar tarefas complexas.
Quanto maior o nível de autonomia concedido ao agente, maior também será a necessidade de mecanismos sólidos de isolamento.
A vulnerabilidade SharedRoot evidencia que confiar apenas na existência de uma VM não é suficiente.
O projeto da arquitetura precisa considerar todos os caminhos pelos quais informações podem atravessar a fronteira entre o ambiente isolado e o sistema hospedeiro.
Esse tipo de abordagem será cada vez mais importante à medida que agentes locais passem a executar tarefas sensíveis em notebooks corporativos, estações de desenvolvimento e ambientes empresariais.
Visão geral e conclusão
A falha no Claude Cowork representa um excelente estudo de caso sobre os desafios da segurança em aplicações baseadas em agentes de IA.
Embora o Apple Virtualization Framework continuasse fornecendo isolamento adequado, uma decisão de arquitetura, compartilhar integralmente o diretório raiz do macOS com a VM Linux, criou uma superfície de ataque que pôde ser explorada quando combinada com a vulnerabilidade pedit COW (CVE-2026-46331).
O resultado foi uma cadeia de exploração capaz de transformar um comprometimento localizado dentro da máquina virtual em acesso aos arquivos do sistema hospedeiro, colocando em risco informações sensíveis de aproximadamente 500 mil usuários antes da aplicação das correções.
O episódio reforça uma lição importante para toda a indústria: ambientes virtualizados não são automaticamente seguros. O verdadeiro nível de proteção depende da combinação entre isolamento rigoroso, princípio do menor privilégio, compartilhamento mínimo de recursos e atualizações constantes dos componentes envolvidos.
À medida que agentes de IA ganham mais autonomia para interagir com sistemas locais, casos como o SharedRoot servirão como referência para a construção de plataformas mais resilientes e seguras.
