O que a Cato encontrou no Cursor
A Cato AI Labs divulgou duas vulnerabilidades críticas no Cursor, o editor de código com IA que, segundo o fabricante, é usado por mais de metade das Fortune 500. Batizadas de DuneSlide e registadas como CVE-2026-50548 e CVE-2026-50549, ambas têm uma pontuação CVSS de 9,8 em 10, ou 9,3 na escala mais recente 4.0. Estão corrigidas no Cursor 3.0, lançado a 2 de abril de 2026, e toda a versão anterior está afetada.
Não havia exploração ativa registada no momento da divulgação. O caminho até à correção não foi liso. A Cato comunicou o problema a 19 de fevereiro, o fabricante rejeitou-o primeiro a 23 de fevereiro, depois reabriu-o, entregou uma correção a 1 de abril e a segunda a 1 de junho, e os números CVE foram atribuídos a 5 de junho.
Como uma pagina web se torna um comando
A técnica é injeção de instruções sem qualquer clique. O programador nunca escreve uma ordem maliciosa. Em vez disso, o agente lê conteúdo em nome do utilizador: uma resposta de um servidor Model Context Protocol ligado, uma página devolvida por uma pesquisa ou um ficheiro dentro do projeto. Esse conteúdo carrega ordens escondidas que o modelo depois obedece.
A primeira falha abusa do parâmetro working_directory. Quando o agente o define para um caminho diferente do padrão, o Cursor acrescenta esse caminho à sua lista de escrita permitida sem verificar, de modo que uma instrução injetada pode sobrescrever um ficheiro do sistema como o binário auxiliar da caixa de areia ou um perfil de shell. A segunda falha aproveita uma verificação de ligações simbólicas que cede ao erro: quando o Cursor não consegue resolver um atalho, confia no caminho dentro do projeto e escreve diretamente sobre o mesmo auxiliar. Sobrescreve esse auxiliar e o comando seguinte corre fora da caixa de areia com todos os direitos do programador.
A lista de leitura e agora a superficie de ataque
A mudança incómoda é o que conta como entrada. Durante anos, o modelo de ameaça de um editor era o código que escrevias e as extensões que instalavas. Um agente autónomo alarga-o a tudo o que lê por conta própria: o README de uma dependência, uma resposta de ferramenta, uma página descarregada. Cada uma delas é agora instrução executável, e o raio de impacto é o sistema operativo em vez de um separador do navegador.
Para uma empresa que distribuiu assistentes de IA pelos seus engenheiros, isto transforma a ferramenta num componente da cadeia de fornecimento com alcance até à máquina, não num extra de produtividade. Sob a NIS2 na UE, transposta em Portugal e acompanhada pelo Centro Nacional de Cibersegurança, a segurança do software que entregas ao pessoal é responsabilidade da administração, e um agente sem correção que confia em conteúdo não verificado cai exatamente nesse dever.
O que os donos devem fazer esta semana
O passo imediato é a higiene de versões. Confirma que cada programador está no Cursor 3.0 ou posterior, porque nada anterior é seguro, e faz a mesma pergunta para qualquer outro editor com agente ou assistente de IDE em uso. Esclarece que ferramentas de IA têm permissão autónoma para escrever ficheiros ou executar comandos, e quem o aprovou.
O passo duradouro é tratar as fontes de leitura de um agente como não fiáveis por omissão. Limita que servidores Model Context Protocol uma equipa pode ligar, mantém os agentes longe de conteúdo externo não revisto quando puderes e exige aprovação humana para as escritas fora do projeto de trabalho. A ferramenta merece ser mantida; as permissões à sua volta pedem agora a mesma disciplina que já aplicas a qualquer componente capaz de tocar numa máquina em produção.
Leia a seguir: O risco de jailbreak passa a ter uma nota · O Agente de IA Confia em Ferramenta Envenenada
