Skip to main content

Atualização dos testes do Snyk Security Labs: editor de código com IA Cursor.com

Escrito por
Headshot of Danny Allan

Danny Allan

feature automation pink

14 de janeiro de 2025

0 minutos de leitura

A equipe do Snyk Security Labs busca identificar e ajudar a corrigir vulnerabilidades em softwares usados por desenvolvedores no mundo todo, com o objetivo maior de melhorar a segurança de software. Para isso, analisamos ferramentas utilizadas por desenvolvedores, incluindo soluções de software novas e populares. Com a ascensão meteórica das ferramentas de IA — especialmente do campo em rápida expansão dos ambientes de desenvolvimento com IA —, passamos a incluir esses softwares em nossos ciclos de pesquisa.

Um desses softwares é o editor de código com IA do Cursor, concorrente do VSCode e de outros IDEs populares entre desenvolvedores. O software integra assistência de IA para programação à experiência de desenvolvimento. Em pesquisas como esta, esperamos não encontrar vulnerabilidades. Mas, se encontrarmos, teremos a oportunidade de divulgá-las de forma responsável para garantir mais segurança a todos os desenvolvedores que usam o software. O Cursor incentiva publicamente o relato de vulnerabilidades de segurança em seu produto e publicou um guia e um canal específico para receber esses relatos.

Como parte da pesquisa, a equipe de pesquisa do Snyk Security Labs identificou várias extensões privadas incluídas no software. As extensões do VSCode — base do editor de código com IA do Cursor — são criadas como dependências clássicas do Node.js e descritas em arquivos package.json. Nossa hipótese para um possível vetor de ataque era que o Cursor tratasse internamente as extensões do VSCode como pacotes NPM e as obtivesse de um repositório interno durante as compilações. Se esse fosse o caso (agora sabemos que não é) e o sistema de compilação estivesse configurado incorretamente, haveria risco de um ataque de confusão de dependências. Embora considerássemos improvável que essa configuração existisse, valia a pena investigá-la: caso nossa hipótese se confirmasse, o impacto nos sistemas do Cursor e em seus usuários poderia ser significativo.

Para testar essa hipótese, publicamos pacotes no repositório público do NPM com nomes que correspondiam aos que suspeitávamos fazer parte do processo de compilação do editor de código com IA do Cursor. Essa é uma técnica comum para testar a possibilidade de confusão de dependências. Era extremamente improvável que esses pacotes fossem instalados por desenvolvedores ou sistemas que não fossem os do Cursor testados — na verdade, era pouco provável que fossem instalados. Ainda assim, as descrições informavam que eram pacotes de teste da equipe do Snyk Security Labs. Também incluímos um endereço de e-mail direto para contato com o autor e definimos um período curto de disponibilidade dos pacotes: 24 horas. O código-fonte desses pacotes era muito pequeno e não tentava ocultar seu comportamento. Os pacotes faziam requisições HTTP para nossos pesquisadores, enviando nome de usuário, nome do host, diretório atual e, nas versões posteriores, variáveis de ambiente. Essas comunicações de saída eram necessárias para determinar se havia ocorrido uma instalação totalmente “às cegas”. Na versão posterior, os pesquisadores da Snyk acrescentaram campos aos dados recebidos para reduzir falsos positivos causados por scanners automatizados que baixaram e executaram os pacotes, algo fora do escopo da prova de conceito. Para enviar relatos confiáveis e precisos à equipe de segurança do Cursor, precisávamos confirmar que as instalações haviam sido executadas pelo Cursor e que o problema identificado era, de fato, um caso legítimo de confusão de dependências.

No fim, o Snyk Security Labs não encontrou indícios de que o Cursor fosse vulnerável a ataques de confusão de dependências. Além disso, nenhum dado confidencial foi divulgado para nós durante os testes. Esses vetores de ataque — de baixa complexidade e probabilidade, mas com alto impacto — são um tema importante de pesquisa, pois a baixa barreira de entrada pode facilitar sua exploração por agentes mal-intencionados. O Snyk Security Labs realiza pesquisas de vulnerabilidades regularmente e busca manter os mais altos padrões de teste para contribuir com a segurança dos desenvolvedores.

Ao testar essas vulnerabilidades, o Snyk Security Labs busca se antecipar aos atacantes e garantir a segurança dos softwares e sistemas usados diariamente por desenvolvedores no mundo todo.

Adorado por desenvolvedores. Confiável para a segurança.

As ferramentas da Snyk, pensadas para desenvolvedores, oferecem segurança integrada e automatizada para atender às suas necessidades de governança e conformidade.

Leia mais

illustration hero ai
Blog

PHP corrige duas vulnerabilidades críticas de RCE sem autenticação (CVE-2026-109618, CVE-2026-109619): atualize agora

Duas falhas críticas no ciclo de requisições do PHP podem permitir execução remota de código sem autenticação. Atualize para uma versão corrigida ou instale um backport do fornecedor para versões mais antigas.

blog feature ai lilac
Blog

Transforme seu backlog de vulnerabilidades em pull requests com remediação agentiva

O Evo Remediation Agent está em Open Preview e traz a resolução automatizada de dependências para o Evo Agentic AppSec. Agora, as equipes de AppSec podem executar campanhas contínuas de remediação

blog feature ai pink
Blog

O risco de um modelo de IA depende do que ele pode acessar

A pontuação de risco de um modelo é apenas parte da história: seu impacto depende dos dados, das ferramentas e das ações que a aplicação pode acessar. Saiba como as equipes de segurança podem verificar esse alcance e escolher controles direcionados.