Cursor security audit uncovers four weaknesses in the code editor's defenses but fails to break authorization

A security audit of Cursor produced a result that is rare for AI tools: the researcher could not bypass server-side authorization or reach premium models through a client vulnerability, but along the way found four notable problems in its security perimeter. The analysis is interesting precisely because it is not an "everything is broken" story. Instead, it is a detailed look at how an AI editor that routes large volumes of developers' code and requests through its servers actually works.

The research began with decompiling Cursor's Electron client, which is built on VS Code. From a single minified JavaScript file of more than 1.1 million lines, the author reconstructed protobuf definitions, an API map, OAuth logic and a list of feature gates. He also showed that the user's JWT contains no claims about subscription or plan: model access rights are checked neither on the client nor through the token's contents, but on the server, using data from the database. For a SaaS product built on expensive LLMs, this is a key architectural choice, because this design is what stops a "free" user from simply swapping local parameters to unlock Claude 4 Opus or another premium model.

After the reverse engineering, the researcher moved on to attacking the API. The first finding is prototype pollution in JSON endpoints tied to subscriptions and promotions. Adding fields such as __proto__ or constructor.prototype to the request body makes the server return 500 Internal Server Error instead of the expected rejection. This does not grant an automatic plan upgrade, but it shows that prototype chain pollution happens before business checks and can alter the validation path.

The second problem is a hidden devRawModelSlug field in AgentRunRequest. It is absent from the client schema, but production servers accept the field, recognize its name and respond with a dedicated error. That error reveals that the system contains a dev mechanism for specifying a backend model directly, bypassing standard routing. The path is currently disabled, but its mere presence in the production environment raises the risk of configuration mistakes.

The other two vulnerabilities are not about bypassing subscriptions but about excessive exposure of internal architecture and incomplete validation. One internal method responds with the message Invalid internal service header, which tells an outsider that the endpoint exists, is protected by separate service-to-service authorization and expects a special header. An external client has no need for that level of detail: a generic 404 or 401 with no internal hints would be safer.

The audit also found that some protobuf fields used in subagent scenarios accept references to premium models without a separate plan check. In practice, this does not change the model that actually answers and does not open a bypass, because routing ignores these fields anyway. Still, this logic widens the attack surface and could become a problem after future product changes.

An important part of the analysis is the list of vectors that did not work. The author tested brute-forcing model names, tampering with JWT claims, injections into the OAuth callback, Stripe webhook replay, confusion between requested_model and model_details, protobuf wire type conflicts and race conditions around subscriptions. None of them yielded a meaningful bypass. The server rejects malformed protobuf tags, does not trust JWT data, validates Stripe signatures and keeps the plan check centralized. That makes the conclusion stronger: the problems are real, but Cursor's baseline security model looks mature and well thought out compared with many AI services that trust the client too much.

The practical lesson extends beyond Cursor itself. For AI SaaS developers, it is a good checklist: don't store privileges in the token, check the plan on the server with every request, validate protobuf strictly and don't leave dev fields in production schemas. For users, it is a sign that even advanced AI IDEs still have a vulnerable surface around billing, internal services and internal model-routing mechanisms. Most importantly, an AI product's security today depends not on how many models it supports, but on how rigorously it separates the client from real access rights on the server.