Auditoría de Seguridad de Cursor Descubre Cuatro Vulnerabilidades en el Editor de Código, pero la Autorización Permanece Segura

Аудит безопасности Cursor показал редкий для AI-инструментов результат: исследователь не смог обойти серверную авторизацию и получить доступ к премиум-моделям через уязвимость в клиенте, но по пути нашёл четыре заметные проблемы в защитном контуре. Разбор интересен именно тем, что это не история про «всё сломано», а детальная проверка того, как устроен AI-редактор, который пропускает через свои серверы большие объёмы кода и запросов разработчиков. Исследование началось с декомпиляции Electron-клиента Cursor, построенного на базе VS Code.

В одном минифицированном JavaScript-файле размером более 1,1 миллиона строк автор восстановил protobuf-описания, карту API, OAuth-логику и список feature gates. Отдельно он показал, что JWT-токен пользователя не содержит claims о подписке или тарифе: права доступа к моделям проверяются не на стороне клиента и не через содержимое токена, а на сервере, по данным из базы. Для SaaS-продукта с дорогими LLM это ключевой архитектурный выбор, потому что именно такая схема не даёт «бесплатному» пользователю просто подменить локальные параметры и открыть себе Claude 4 Opus или другую премиум-модель.

После реверс-инжиниринга исследователь перешёл к атакам на API. Первая находка — prototype pollution в JSON-эндпоинтах, связанных с подпиской и промоакциями. Если в тело запроса добавить поля вроде __proto__ или constructor.

prototype, сервер вместо ожидаемого отказа возвращает 500 Internal Server Error. Это не даёт автоматического повышения тарифа, но показывает, что загрязнение prototype chain происходит раньше бизнес-проверок и способно менять путь валидации. Вторая проблема — скрытое поле devRawModelSlug в AgentRunRequest.

Его нет в клиентской схеме, но production-серверы принимают это поле, распознают его имя и отвечают отдельной ошибкой, из которой видно, что в системе существует dev-механизм прямого указания backend-модели в обход стандартного routing. Сейчас этот путь отключён, но сам факт его присутствия в production-контуре повышает риск ошибок конфигурации. Ещё две уязвимости связаны уже не с обходом подписки, а с лишним раскрытием внутренней архитектуры и неполной валидацией.

Один из внутренних методов отвечает сообщением Invalid internal service header, из которого можно понять, что эндпоинт существует, защищён отдельной service-to-service авторизацией и ожидает специальный заголовок. Для внешнего клиента такая детализация не нужна: безопаснее было бы отвечать универсальным 404 или 401 без внутренних подсказок. Кроме того, аудит показал, что некоторые protobuf-поля для subagent-сценариев принимают ссылки на премиум-модели без отдельной plan-проверки.

На практике это не меняет фактическую модель ответа и не открывает bypass, потому что routing всё равно игнорирует эти поля, но такая логика расширяет attack surface и может стать проблемой после будущих изменений продукта. Важная часть разбора — список векторов, которые не сработали. Автор проверил bruteforce имён моделей, подмену JWT-claims, инъекции в OAuth callback, replay Stripe webhook, путаницу между requested_model и model_details, конфликты wire types в protobuf и гонки вокруг подписки.

Существенного обхода нигде не получилось. Сервер отклоняет некорректные protobuf-теги, не доверяет данным из JWT, валидирует подписи Stripe и держит plan check централизованным. Это делает вывод сильнее: проблемы действительно есть, но базовая модель защиты у Cursor выглядит зрелой и продуманной по сравнению со многими AI-сервисами, где клиенту доверяют слишком много.

Практический смысл этой истории шире самого Cursor. Для разработчиков AI-SaaS это хороший чеклист: не хранить привилегии в токене, проверять тариф на сервере при каждом запросе, жёстко валидировать protobuf и не оставлять dev-поля в production-схемах. Для пользователей это сигнал, что даже у продвинутых AI-IDE остаётся уязвимая поверхность вокруг биллинга, внутренних сервисов и служебных механизмов маршрутизации моделей.

И главное: безопасность AI-продукта сегодня определяется не тем, сколько моделей он поддерживает, а тем, насколько дисциплинированно он отделяет клиент от реальных прав доступа на сервере.