Cursor Security Audit Discovers Four Vulnerabilities in Code Editor Protection, but Authorization Remains Secure

A Cursor security audit revealed a rare result for AI tools: the researcher was unable to bypass server-side authorization and gain access to premium models through a client-side vulnerability, but found four notable issues in the security perimeter along the way. The review is interesting precisely because it's not a story about "everything broke," but rather a detailed examination of how an AI code editor is structured—one that channels large volumes of code and developer requests through its servers. The investigation began with decompiling Cursor's Electron client, built on VS Code.

In a single minified JavaScript file exceeding 1.1 million lines, the author recovered protobuf descriptions, an API map, OAuth logic, and a feature gate list. Separately, he demonstrated that the user's JWT token contains no claims about subscription or tier: access rights to models are not checked on the client side and not through token contents, but on the server, based on database data.

For a SaaS product with expensive LLMs, this is a key architectural choice, precisely because such a scheme prevents a "free" user from simply spoofing local parameters and unlocking Claude 4 Opus or another premium model. After reverse engineering the API, the researcher moved on to attacks on the API. The first finding—prototype pollution in JSON endpoints related to subscription and promotions.

If fields like __proto__ or constructor.prototype are added to the request body, the server returns a 500 Internal Server Error instead of the expected rejection. This doesn't grant automatic tier upgrades, but shows that prototype chain pollution occurs before business logic checks and can alter the validation path.

The second issue—a hidden devRawModelSlug field in AgentRunRequest. It doesn't exist in the client schema, but production servers accept this field, recognize its name, and respond with a separate error that reveals the system has a dev mechanism for directly specifying the backend model, bypassing standard routing. Currently this path is disabled, but its very presence in the production perimeter increases the risk of configuration errors.

Two more vulnerabilities stem not from subscription bypass, but from unnecessary exposure of internal architecture and incomplete validation. One internal method responds with "Invalid internal service header," from which you can infer that the endpoint exists, is protected by separate service-to-service authorization, and expects a special header. For an external client, such detail is unnecessary: it would be safer to respond with a universal 404 or 401 without internal hints.

Additionally, the audit revealed that some protobuf fields for subagent scenarios accept links to premium models without a separate plan check. In practice, this doesn't change the actual response model and doesn't open a bypass, because routing ignores these fields anyway, but such logic expands the attack surface and could become a problem after future product changes. An important part of the review—a list of vectors that didn't work.

The author tested model name brute force, JWT claim spoofing, OAuth callback injection, Stripe webhook replay, confusion between requested_model and model_details, protobuf wire type conflicts, and race conditions around subscription. No significant bypass succeeded anywhere. The server rejects incorrect protobuf tags, doesn't trust JWT data, validates Stripe signatures, and keeps plan checks centralized.

This makes the conclusion stronger: problems do exist, but Cursor's basic security model looks mature and thoughtful compared to many AI services that trust the client too much. The practical significance of this story extends beyond Cursor itself. For AI SaaS developers, this is a good checklist: don't store privileges in tokens, check tier on the server with every request, strictly validate protobuf, and don't leave dev fields in production schemas.

For users, it's a signal that even advanced AI IDEs have a vulnerable surface around billing, internal services, and model routing mechanisms. And most importantly: today, the security of an AI product is defined not by how many models it supports, but by how disciplined it is in separating the client from real access rights on the server.