Auditoria de Segurança do Cursor Descobre Quatro Vulnerabilidades no Editor de Código, mas Autorização Permanece Segura

Uma auditoria de segurança do Cursor revelou um resultado raro para ferramentas de IA: o pesquisador não conseguiu contornar a autorização do lado do servidor e ganhar acesso aos modelos premium através de uma vulnerabilidade do lado do cliente, mas encontrou quatro problemas notáveis no perímetro de segurança no caminho. A revisão é interessante precisamente porque não é uma história sobre "tudo quebrou", mas sim um exame detalhado de como um editor de código com IA é estruturado—um que canaliza grandes volumes de código e requisições de desenvolvedores através de seus servidores. A investigação começou com a descompilação do cliente Electron do Cursor, construído sobre VS Code.

Em um único arquivo JavaScript minificado excedendo 1,1 milhões de linhas, o autor recuperou descrições protobuf, um mapa de API, lógica OAuth e uma lista de feature gates. Separadamente, ele demonstrou que o token JWT do usuário não contém claims sobre assinatura ou plano: os direitos de acesso aos modelos não são verificados no lado do cliente e não através do conteúdo do token, mas no servidor, com base nos dados do banco de dados. Para um produto SaaS com LLMs caros, esta é uma escolha arquitetônica chave, precisamente porque tal esquema impede um usuário "gratuito" de simplesmente falsificar parâmetros locais e desbloquear Claude 4 Opus ou outro modelo premium.

Após a engenharia reversa do API, o pesquisador passou para ataques na API. A primeira descoberta—poluição de protótipo em endpoints JSON relacionados a assinatura e promoções. Se campos como __proto__ ou constructor.

prototype forem adicionados ao corpo da requisição, o servidor retorna um erro 500 Internal Server Error em vez da rejeição esperada. Isto não concede atualizações automáticas de plano, mas mostra que a poluição da cadeia de protótipos ocorre antes das verificações de lógica de negócios e pode alterar o caminho de validação. O segundo problema—um campo oculto devRawModelSlug em AgentRunRequest.

Ele não existe no esquema do cliente, mas os servidores de produção aceitam este campo, reconhecem seu nome e respondem com um erro separado que revela que o sistema tem um mecanismo dev para especificar diretamente o modelo de backend, contornando o roteamento padrão. Atualmente este caminho está desativado, mas sua mera presença no perímetro de produção aumenta o risco de erros de configuração. Mais duas vulnerabilidades não provêm de contorno de assinatura, mas de exposição desnecessária de arquitetura interna e validação incompleta.

Um método interno responde com "Invalid internal service header", de onde você pode inferir que o endpoint existe, é protegido por autorização separada entre serviços e espera um cabeçalho especial. Para um cliente externo, tal detalhe é desnecessário: seria mais seguro responder com um 404 ou 401 universal sem dicas internas. Além disso, a auditoria revelou que alguns campos protobuf para cenários de subagente aceitam links para modelos premium sem uma verificação de plano separada.

Na prática, isto não altera o modelo de resposta real e não abre um contorno, porque o roteamento ignora estes campos de qualquer forma, mas tal lógica expande a superfície de ataque e poderia se tornar um problema após futuras mudanças de produtos. Uma parte importante da revisão—uma lista de vetores que não funcionaram. O autor testou força bruta de nomes de modelos, falsificação de claims JWT, injeção de callback OAuth, replay de webhook Stripe, confusão entre requested_model e model_details, conflitos de tipos de wire do protobuf e condições de corrida em torno de assinatura.

Nenhum contorno significativo funcionou em lugar algum. O servidor rejeita tags protobuf incorretas, não confia em dados JWT, valida assinaturas Stripe e mantém verificações de plano centralizadas. Isto torna a conclusão mais forte: problemas realmente existem, mas o modelo de segurança básico do Cursor parece maduro e reflexivo comparado a muitos serviços de IA que confiam o cliente demais.

O significado prático desta história se estende além do próprio Cursor. Para desenvolvedores de IA SaaS, este é um bom checklist: não armazene privilégios em tokens, verifique plano no servidor a cada requisição, valide protobuf estritamente e não deixe campos dev em esquemas de produção. Para usuários, é um sinal de que até IDEs avançados de IA têm uma superfície vulnerável em torno de cobrança, serviços internos e mecanismos de roteamento de modelos.

E mais importante: hoje, a segurança de um produto de IA é definida não por quantos modelos ele suporta, mas por quão disciplinado ele é em separar o cliente dos direitos de acesso reais no servidor.