SharedRoot: a vulnerabilidade em Claude Cowork para macOS que permitia a uma VM ler e escrever em todo o Mac

Pesquisadores de segurança revelaram uma vulnerabilidade crítica na versão de desktop de Anthropic Claude Cowork para macOS que permitia a um agente escapar de sua máquina virtual Linux e ler ou escrever arquivos em todo o sistema do Mac onde a sessão local foi executada. O achado, batizado como SharedRoot por aqueles que descobriram, expõe o risco real de correr agentes baseados em VMs locais com montagem ampla do sistema de arquivos e capacidades de rede sem restrições adequadas.

Segundo a empresa que reportou a falha, Accomplish AI, a técnica funcionava porque a VM convidada montava o sistema de arquivos do anfitrião com acesso de leitura-escrita em um ponto acessível para o usuário root dentro do convidado. Uma cadeia de exploração aproveitava a capacidade de criar espaços de nomes não privilegiados e a carga do subsistema act_pedit do kernel Linux para desencadear um transbordamento conhecido na rota pedit COW (associado à classificação de tráfego), com o que o processo na VM obteve privilégios equivalentes ao root na convidada e, através da montagem compartilhada, acesso a todo o Mac do usuário.

O perigo prático é simples e grave: um agente que consegue esta escalada pode ler chaves SSH, credenciais armazenadas, arquivos com tokens de nuvem e outros segredos do usuário que executa o aplicativo no desktop. Os descubridores estimaram que até meio milhão de instâncias locais poderiam ter sido expostas antes de Anthropic mudar o comportamento por defeito para a execução na nuvem.

Anthropic respondeu fechando o relatório como informativo e mudando a execução por defeito à nuvem, o que reduz o vetor de ataque para a maioria dos usuários. No entanto, aqueles que escolhem explicitamente executar sessões de Cowork em local continuam em risco se não aplicarem mitigações adicionais ou se o kernel/imagem de VM não estiver adesivo. Este episódio destaca uma lição maior: a ergonomia de executar modelos localmente pode chocar com limitações estruturais de segurança quando o desenho confia em montagem compartilhada e em módulos do kernel que podem ser explorados de um contexto não privilegiado.

Do ponto de vista técnico, a vulnerabilidade é representativa de uma classe recorrente em subsistemas de rede e programação do kernel: um módulo que se autoloadea, uma rota de configuração acessível por usuários não privilégios e uma falha de memória que converte essa rota em uma escala eficaz de privilégios. Como resumo, o sistema transdérmico de um CVE específico resolve essa instância, mas deixa intacto o padrão que permitirá que surja a seguinte falha similar se não forem medidas estruturais de contenção.

Para usuários que utilizem Claude Cowork no macOS recomendo, nesta ordem: garantir que a aplicação esteja atualizada e prefere a execução na nuvem se não for imprescindível trabalhar em local; revisar as preferências e evitar compartilhar a raiz do sistema (/) com a VM; montar apenas as pastas concretas que a sessão necessita e, quando possível, fazê-lo em modo leitura; e rodar chaves e credenciais se suspeitar que uma sessão local pôde ter sido comprometida. Também convém auditar arquivos recentes e registros do sistema por atividade incomum e, na dúvida, revogar tokens ou chaves SSH e gerar de novo.

Para administradores e desenvolvedores de soluções que embebem agentes em VMs, as recomendações técnicas práticas são claras: não montar todo o sistema do anfitrião com permissões de escrita na VM; limitar as capacidades atribuídas ao processo de usuário dentro do recipiente ou VM (evitar CAP_NET_ADMIN se não for estritamente necessário); desativar ou restringir espaços de nomes não privilegiados quando o ambiente o permita; endurecer filtros seccomp para reduzir chamadas permitidas; impedir a autoload de módulos do kernel a partir de contextos expostos; e executar processos de gestão como coworkd em um nome de montagem e usuário próprio com políticas de apenas leitura e ProtectSystem=strict para que não possam ser rejetados por usuários de sessão.

Além destas medidas pontuais, convém adoptar uma abordagem de defesa em profundidade: conter o impacto de uma possível escalada da VM, fazendo com que, mesmo com guest-root, não haja vetores fáceis para atacar o anfitrião. Montagens read-only, menor exposição de dispositivos virtuais e uma política clara sobre quando é aceitável executar modelos localmente frente a executar na nuvem ajudam a reduzir a janela de exposição.

Este incidente lembra a tensão entre funcionalidade offline e segurança: a capacidade de executar agentes complexos em uma equipe local tem vantagens de latência e privacidade, mas exige controles mais rigorosos no isolamento das VMs e no kernel. Enquanto isso, os fornecedores devem priorizar não apenas adesivos reativos, mas mudanças de design que eliminem a dependência de caminhos de exploração repetiveis.

Se você procura documentação técnica de referência sobre o quadro de virtualização da Apple e sobre como o Linux gere espaços de nomes e capacidades, você pode consultar a documentação oficial da Apple em Apple Virtualization Framework e o guia do kernel em kernel.org sobre o utilizador namespaces. Manter-se informado e aplicar medidas de mitigação é a forma mais prática de reduzir o risco enquanto a comunidade corrige a superfície de ataque.