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, a 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 caso, entregou uma primeira correção a 1 de abril e a segunda a 1 de junho. Os números CVE foram atribuídos a 5 de junho.

Como uma página web se torna um comando

A técnica é a injeção de instruções sem qualquer clique. O programador nunca escreve uma ordem maliciosa. É o agente que lê conteúdo em nome do utilizador: a resposta de um servidor Model Context Protocol ligado, uma página devolvida por uma pesquisa na web ou um ficheiro dentro do projeto. Esse conteúdo transporta ordens escondidas, a que o modelo acaba por obedecer.

A primeira falha abusa do parâmetro working_directory. Quando o agente o define para um caminho fora do padrão, o Cursor acrescenta esse caminho à lista de escrita permitida sem o verificar. Uma instrução injetada pode assim sobrescrever um ficheiro do sistema, como o binário auxiliar da sandbox ou um perfil de shell. A segunda falha aproveita uma verificação de ligações simbólicas que cede perante o erro: quando o Cursor não consegue resolver um atalho, confia no caminho interno ao projeto e escreve diretamente sobre esse mesmo auxiliar. Uma vez sobrescrito o auxiliar, o comando seguinte corre fora da sandbox com todos os direitos do programador.

A lista de leitura é agora a superfície de ataque

A mudança incómoda está no que conta como entrada. Durante anos, o modelo de ameaça de um editor de código era o código que se escrevia e as extensões que se instalavam. Um agente autónomo alarga-o a tudo o que lê por conta própria: o README de uma dependência, a resposta de uma ferramenta, uma página descarregada. Cada um destes elementos é hoje 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 programação com IA pelos seus engenheiros, a ferramenta passa a ser um componente da cadeia de fornecimento com alcance até à máquina, e não um extra de produtividade. Ao abrigo da NIS2 na UE, e dos deveres equivalentes que as empresas britânicas já assumem, a segurança do software que entrega ao pessoal é responsabilidade da administração, e um agente sem correção que confia em conteúdo não verificado cai em cheio nesse dever.

O que os donos devem fazer esta semana

O passo imediato é a higiene de versões. Confirme que cada programador está no Cursor 3.0 ou posterior, porque nada anterior é seguro, e faça a mesma pergunta sobre qualquer outro editor com agente ou assistente de IDE em uso. Esclareça que ferramentas de IA têm permissão autónoma para escrever ficheiros ou executar comandos, e quem a aprovou.

O passo duradouro é tratar as fontes de leitura de um agente como não fiáveis por omissão. Limite que servidores Model Context Protocol uma equipa pode ligar, mantenha os agentes longe de conteúdo externo não revisto sempre que puder e exija 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á aplica a qualquer componente capaz de tocar numa máquina em produção.

Leia a seguir: Uma IA conduziu sozinha um ataque de ransomware inteiro  |  Falha Squid de 29 anos expõe logins em texto simples