Disclaimer: исследование проводилось исключительно в образовательных целях. Все найденные уязвимости были задокументированы. Никакие данные третьих лиц не были скомпрометированы. Автор не несёт ответственности за использование описанных техник.

Вступление

Cursor — это AI-редактор на базе VS Code, который обрабатывает миллионы строк кода разработчиков через свои серверы. Возникает естественный вопрос: насколько надёжна его серверная модель авторизации, особенно между бесплатными пользователями и доступом к мощным моделям вроде Claude 4 Opus?

Спойлер: серьёзного обхода защиты обнаружить не удалось — Cursor хорошо защищён. Однако в ходе анализа были выявлены 4 уязвимости класса CVE. Полностью реверс-инжинирингом восстановлен API-интерфейс, извлечены protobuf-схемы из 1,1 млн строк минифицированного JavaScript, а также обнаружен скрытый dev-бэкдор на production-серверах.

Разведка: декомпиляция клиента

Cursor построен на Electron и использует архитектуру VS Code. Весь клиентский код упакован в один JavaScript-бандл объёмом 1,144,696 строк. Этот файл стал основным источником информации: в нём содержатся protobuf-определения, URL API, логика OAuth, feature-флаги Statsig и маршрутизация моделей.

Извлечение protobuf-схем

Cursor использует Connect-RPC — современный RPC-фреймворк на основе HTTP/2. Все сервисы описаны прямо в JS-бандле. С помощью комбинации grep, sed и ручного анализа удалось извлечь полную схему, включая запрос AgentRunRequest.

Ключевое открытие: поле devRawModelSlug (номер 18) отсутствует в клиентском коде, но сервер его принимает и обрабатывает. Это стало одной из уязвимостей.

Извлечение токенов

Аутентификация в Cursor хранится в локальной SQLite-базе. Основной токен — JWT, содержащий стандартные claims. Важно: в токене нет информации о подписке. Проверка тарифного плана происходит исключительно на сервере.

Архитектура

Протокол: Connect-RPC

Connect-RPC передаёт protobuf-сообщения через HTTP/2 с использованием фреймов:

• flags=0x00 — фрейм с данными
• flags=0x02 — трейлер с метаданными или ошибками в формате JSON

Checksum-алгоритм

Cursor применяет кастомный checksum для валидации запросов. Алгоритм был реверс-инжинирингом извлечён из файла workbench.desktop.main.js. Он основан на временной метке и является детерминированным, что позволяет легко воспроизвести его.

Полная карта API-surface

gRPC-сервисы (Connect-RPC)

Основные сервисы:

• agent.v1.AgentService — ServerStreaming, GetDefaultModelForCli, UploadConversationBlobs
• aiserver.v1.DashboardService — ActivatePromotion, GetAllowedModelIntents
• aiserver.v1.BackgroundComposerService — StartBackgroundComposerFromSnapshot, AttachBackgroundComposer, ListBackgroundComposers

REST-эндпоинты

Ключевые:

• /auth/full_stripe_profile — профиль подписки
• /auth/start-subscription-now — активация подписки
• /user — информация о пользователе

Statsig Feature Gates

Из исходного кода извлечено более 40 feature-флагов, управляющих поведением приложения.

CVE-1: Prototype Pollution (CWE-1321)

Уровень серьёзности: Средний (DoS, потенциальная эскалация)
Эндпоинт: POST /auth/start-subscription-now
Воздействие: Сервер возвращает 500 вместо 400, что указывает на загрязнение цепочки прототипов.

JSON-эндпоинты Cursor не санитизируют поля __proto__ и constructor. При отправке таких полей сервер падает с ошибкой 500, а не возвращает корректный 400-й статус.

Тесты показали, что все варианты с __proto__ вызывают 500-ю ошибку. Это означает, что загрязнение происходит до проверки подписки.

Аналогичное поведение наблюдается на эндпоинте ActivatePromotion, где pollution меняет путь валидации.

Последствия:

• DoS: любой аутентифицированный пользователь может вызвать сбой на биллинговых эндпоинтах
• Потенциальная эскалация: если загрязнение затронет общее состояние, возможна эксплуатация (маловероятно, но зависит от архитектуры)

CVE-2: devRawModelSlug — скрытый бэкдор (CWE-489)

Уровень серьёзности: Средний (активный отладочный код в production)
Поле: AgentRunRequest.dev_raw_model_slug (поле 18)
Воздействие: наличие механизма прямого обхода маршрутизации моделей в боевом окружении.

Обнаружение

При тестировании всех полей AgentRunRequest (1–50) поле 18 ведёт себя иначе:

1. Отсутствует в клиентском коде — не найдено при поиске по 1,1 млн строк
2. Сервер его парсит и валидирует, возвращая специфическую ошибку
3. Проверка происходит до проверки тарифа: при f3=default и f18=gpt-4o сервер отвечает ошибкой по devRawModelSlug, а не plan_block
4. Поведение одинаково на всех серверах

Почему это CWE-489

Поле devRawModelSlug — это механизм для разработчиков, позволяющий напрямую указать модель, минуя маршрутизацию. В production он должен быть отключён, но:

• Код обработки присутствует в production-бинарнике
• Сервер парсит и валидирует поле
• Ошибка раскрывает имя поля, выдавая внутреннюю архитектуру
• При ошибке конфигурации или активации feature-флага поле может стать рабочим

CVE-3: Раскрытие заголовка внутреннего сервиса (CWE-200)

Эндпоинт: GET /agent.v1.AgentService/GetAllowedModelIntents
Воздействие: раскрытие архитектуры внутреннего service mesh.

При вызове метода с обычным токеном сервер возвращает "Invalid internal service header", а не стандартные 401 или 404. Это раскрывает:

1. Эндпоинт существует
2. Используется service-to-service аутентификация
3. Есть отдельный механизм авторизации для внутренних сервисов

Брутфорс заголовков (25+ комбинаций) не дал доступа — внутренний токен не зависит от пользовательского.

CVE-4: Инъекция полей Protobuf и путаница с wire-типами

7.1 Дублирование поля (Double Field Injection)

Protobuf позволяет отправить одно поле дважды. По спецификации, последнее значение должно перезаписать предыдущее. Тест показал, что сервер корректно обрабатывает последнее значение. Однако он не отклоняет дубли — это нарушение строгого парсинга.

7.2 Путаница с wire-типами

При отправке model_id (обычно строка, wire type 2) как varint (wire type 0) сервер отклоняет запрос с ошибкой "parse binary: illegal tag". Парсер оказался достаточно строгим.

7.3 Инъекция subagent-полей

Поля 14 и 15 (selected_subagent_models и selected_subagent_model_details) принимают премиальные модели без проверки подписки. Запрос проходит, но в ответе используется модель по умолчанию (Codex 5.3). Поля игнорируются при маршрутизации, но не валидируются — это увеличивает поверхность атаки при будущих изменениях.

Протестированные векторы без результата

Полный список проверенных, но нерабочих векторов:

• Подбор названий моделей (42 варианта) — блокируется проверкой тарифа
• Манипуляция JWT — claims не содержат план, проверка идёт по БД
• OAuth callback injection — nonce валидируется
• Replay Stripe webhook — требуется подпись
• Host header override — мешает балансировщик
• gRPC Server Reflection — отключено
• Race condition на подписку — проверка атомарна

Что Cursor делает правильно

Cursor демонстрирует зрелый подход к безопасности:

1. Проверка тарифа на сервере: JWT не содержит привилегий, проверка происходит по БД при каждом запросе.
2. Строгий парсинг protobuf: wire type confusion отклоняется, неизвестные поля не влияют на маршрутизацию.
3. Валидация подписи Stripe: webhook защищён от replay-атак.
4. OAuth nonce: WorkOS проверяет nonce, предотвращая инъекции.
5. Единая проверка модели: поля model_details и requested_model проходят одинаковую валидацию.
6. Connect-RPC вместо raw gRPC: упрощает аудит и мониторинг.

Выводы и рекомендации

Найденные уязвимости

CURSOR-2025-001: Prototype Pollution — __proto__ вызывает 500 на биллинговых эндпоинтах
CURSOR-2025-002: Active Debug Code — devRawModelSlug парсится в production
CURSOR-2025-003: Info Disclosure — GetAllowedModelIntents раскрывает service mesh
CURSOR-2025-004: Improper Input Validation — subagent-поля не валидируются

Рекомендации для Cursor

1. Санитизировать __proto__ и constructor при парсинге JSON. Использовать Object.create(null) или библиотеки вроде secure-json-parse.
2. Удалить devRawModelSlug из production-схемы или не возвращать имя поля в ошибках.
3. Унифицировать ошибки авторизации: GetAllowedModelIntents должен возвращать 404, а не специфическое сообщение.
4. Валидировать все proto-поля: отклонять запросы с неожиданными полями в selected_subagent_models и selected_subagent_model_details.

Инструментарий

Исследование проведено с помощью:

• Python + httpx (HTTP/2 клиент)
• Ручная сериализация protobuf (без .proto файлов)
• grep / sed (анализ JS)
• SQLite3 (извлечение токенов)

Cursor — один из самых безопасных AI-продуктов, которые мне приходилось исследовать. Проверка тарифа полностью серверная, JWT не содержит привилегий, парсинг protobuf строгий. Тем не менее, prototype pollution и наличие dev-бэкдора в production — реальные проблемы, требующие исправления.

Если вы разрабатываете SaaS с серверной авторизацией, используйте этот чеклист:

• ✅ Не храните привилегии в JWT
• ✅ Проверяйте план из БД на каждый запрос
• ✅ Используйте строгий proto parsing
• ❌ Не оставляйте dev-поля в production proto
• ❌ Не раскрывайте внутренние имена через ошибки
• ❌ Санитизируйте __proto__ в JSON

Disclaimer: исследование проводилось исключительно в образовательных целях. Все найденные уязвимости были задокументированы. Никакие данные третьих лиц не были скомпрометированы. Автор не несёт ответственности за использование описанных техник.

Вступление

Cursor — AI-powered IDE на базе VS Code, которая обрабатывает миллионы строк кода разработчиков через свои серверы. Когда я задумался о безопасности этого продукта, возник вопрос: насколько надёжна серверная модель авторизации, которая стоит между бесплатным пользователем и Claude 4 Opus?

Спойлер: серьёзного bypass я не нашёл — Cursor реально неплохо защищён. Но по пути я обнаружил4 уязвимости класса CVE, полностью реверс-инжинирнул API-surface, извлёк protobuf-схемы из 1.1M строк минифицированного JS и нашёлскрытый dev-бэкдорв production-серверах.

Вот что получилось.

Содержание

1. Разведка: декомпиляция клиента
2. Архитектура: Connect-RPC, протоколы, аутентификация
3. Полная карта API-surface
4. CVE-1: Prototype Pollution (CWE-1321)
5. CVE-2: devRawModelSlug — скрытый бэкдор (CWE-489)
6. CVE-3: Internal Service Header Information Disclosure (CWE-200)
7. CVE-4: Protobuf Field Injection & Wire Type Confusion
8. Протестированные вектора без результата
9. Что Cursor делает правильно
10. Выводы и рекомендации

1. Разведка: декомпиляция клиента

Cursor основан на VS Code (Electron). Весь клиентский код лежит в:

1,144,696 строкминифицированного JavaScript. Этот файл — золотая жила: тут все protobuf-определения, URL-ы API, OAuth-флоу, Statsig feature gates и логика маршрутизации моделей.

Извлечение protobuf-схем

Cursor используетConnect-RPC(https://connectrpc.com/) — современный RPC-фреймворк поверх HTTP/2. Все сервисы определены прямо в JS-бандле:

Для извлечения полей использовал цепочку grep → sed → ручной анализ:

Результат — полная proto-схемаAgentRunRequest:

Ключевая находка: поле 18 (devRawModelSlug) отсутствует в клиентском коде, но сервер его принимает и обрабатывает. Об этом ниже.

Извлечение токенов

Cursor хранит аутентификацию в SQLite:

JWT-токен содержит стандартные claims:

Заметьте:никаких claims о подписке или плане. Проверка подписки происходит полностью на сервере.

2. Архитектура

Протокол: Connect-RPC

Connect-RPC фреймирует protobuf в HTTP/2:

• flags=0x00: data frame
• flags=0x02: trailer frame (JSON с ошибками/метаданными)

Пример фрейминга:

Checksum-алгоритм

Cursor использует кастомный checksum для валидации запросов:

Алгоритм реверснут изworkbench.desktop.main.js. Timestamp-based, детерминированный — воспроизводится тривиально.

Список серверов

3. Полная карта API-surface

gRPC-сервисы (Connect-RPC)

agent.v1.AgentService

ServerStreaming

agent.v1.AgentService

GetDefaultModelForCli

agent.v1.AgentService

UploadConversationBlobs

aiserver.v1.DashboardService

aiserver.v1.DashboardService

ActivatePromotion

aiserver.v1.DashboardService

GetAllowedModelIntents

aiserver.v1.BackgroundComposerService

StartBackgroundComposerFromSnapshot

aiserver.v1.BackgroundComposerService

AttachBackgroundComposer

ServerStreaming

aiserver.v1.BackgroundComposerService

ListBackgroundComposers

REST-эндпоинты

/auth/full_stripe_profile

Профиль подписки

/auth/start-subscription-now

Активация подписки

Информация о пользователе

Statsig Feature Gates (извлечено 40+)

4. CVE-1: Prototype Pollution (CWE-1321)

Severity: Medium (DoS, потенциальная эскалация)Endpoint:POST /auth/start-subscription-nowImpact: Server crash (HTTP 500), изменение пути обработки

JSON-эндпоинты Cursor парсят тело запроса без санитизации__proto__. При отправке payload с__proto__сервер возвращает500 Internal Server Errorвместо ожидаемого400 Cannot upgrade free user.

Результаты тестирования

Ожидаемый ответ

Фактический ответ

{"tier": "pro"}

400 “Cannot upgrade free user”

{"tier": "pro", "__proto__": {...}}

500 “Error”✗

{"constructor": {"prototype": {...}}}

500 “Error”✗

{"__proto__": {"tier": "pro"}}

500 “Error”✗

Все 10 вариацийс__proto__вызывают 500 вместо 400. Это подтверждает, что объект prototype chain загрязняется до момента проверки подписки, вызывая необработанное исключение.

Аналогичное поведение наActivatePromotion:

ЭндпоинтActivatePromotionс__proto__возвращаетinvalid_argumentвместоUnknown promo type id— pollution меняет путь валидации.

• DoS: любой аутентифицированный пользователь может вызвать 500-ку на billing endpoints
• Потенциальная эскалация: если pollution проникает в shared state (маловероятно в production, но зависит от архитектуры)

5. CVE-2: devRawModelSlug — скрытый бэкдор (CWE-489)

Severity: Medium (Active Debug Code in Production)Field:AgentRunRequest.dev_raw_model_slug(proto field 18)Impact: Наличие dev-механизма прямого bypass model routing в production

Обнаружение

При систематическом сканированиивсехproto-полей (1-50) наAgentRunRequest:

Поля 6, 7, 8, 10-17 → parse error или plan_block (ожидаемо).Поле 18→ уникальный ответ:

1. Поле 18 отсутствует в клиентском коде— grep по 1.1M строк не находитdevRawModelSlugв proto-определениях клиента
2. Сервер его парсит и валидирует— возвращает специфическое сообщение об ошибке, а не generic parse error
3. Проверка происходит ДО plan check— приf3=default(проходит free check) +f18=gpt-4o→ ошибка devRawModelSlug, а не plan_block
4. Одинаково на ВСЕХ серверах:

Почему это CWE-489

devRawModelSlug— это механизм для разработчиков, позволяющийнапрямую указать backend-модель, минуя стандартную маршрутизацию. В production он отключён, но:

• Код обработкиприсутствуетв production-бинарнике
• Серверпарсит и валидируетэто поле (не игнорирует)
• Ошибка выдаётимя поля, раскрывая внутреннюю архитектуру
• Если флаг отключения будет снят (ошибка конфигурации, feature flag), полемгновенно станет рабочим

6. CVE-3: Internal Service Header Leak (CWE-200)

Endpoint:GET /agent.v1.AgentService/GetAllowedModelIntentsImpact: раскрытие архитектуры внутреннего service mesh

МетодGetAllowedModelIntentsобнаружен в клиентском JS:

При вызове с обычным Bearer-токеном:

Ответ"Invalid internal service header"вместо generic401 Unauthorizedили404 Not Foundраскрывает:

1. Эндпоинт существуети обрабатывается (не 404)
2. Используется service-to-service аутентификация(внутренний заголовок)
3. Есть отдельный механизм авторизациидля внутренних сервисов

Брутфорс заголовков (25+ комбинаций) не дал результата — внутренний токен не является производным от пользовательского.

7. CVE-4: Protobuf Field Injection & Wire Type Confusion

7.1 Дублирование field 3 (Double Field Injection)

Protobuf позволяет отправить одно и то же поле дважды. По спецификации, для singular-полей последнее значение побеждает. Но что если plan check и routing читают разные значения?

Результат: сервер корректно берёт последнее значение для обоих проверок. Bypass не работает, но серверне отклоняетдублированное поле — это нарушение принципа strict parsing.

7.2 Wire Type Confusion

Отправкаmodel_id(обычно string, wire type 2) как varint (wire type 0):

Результат:parse binary: illegal tag— сервер отклоняет. Парсер достаточно строгий.

7.3 Subagent Field Injection

Поля 14 (selected_subagent_models) и 15 (selected_subagent_model_details) принимают premium-моделибез plan check:

Запрос проходит и стримится. Однако, при анализе ответа —модель-ответчик идентичнаобычному запросу с “default” (Codex 5.3). Поля 14/15 игнорируются при routing, ноне валидируются— это увеличивает attack surface при будущих изменениях.

8. Что ещё было протестировано (без результата)

Для полноты картины — полный список проверенных векторов:

Почему не работает

Model name bruteforce (42 модели)

Plan blocked

Серверная проверка по имени

requested_modelvsmodel_detailsconfusion

Одна и та же проверка

JWT claim manipulation

Claims не содержат план; проверка из БД

OAuth callback injection

WorkOS nonce validation

Stripe webhook replay

Signature verification

start-subscription-nowс разными tier

Требует активную подписку

Content-Type confusion (gRPC vs Connect)

Строгая проверка Content-Type

Internal service header brute force

Токен не derivable

Host header override

Load balancer routing

custom_system_prompt(field 8)

“unknown option --system-prompt”

harness+subagent_type_name

Plan blocked

Не влияют на plan check

Integer overflow в billing

Endpoints не существуют

gRPC Server Reflection

Feature flag headers

Серверные gates не управляются клиентом

Race condition на subscription

Атомарная проверка

9. Что Cursor делает правильно

Нужно отдать должное — по результатам аудита, Cursor демонстрируетзрелуюsecurity-модель:

1. Plan check полностью серверный— никаких claims в JWT о подписке. Проверка идёт из базы данных на каждый запрос.
2. Строгий protobuf parsing— wire type confusion отклоняется; неизвестные поля не влияют на routing.
3. Stripe webhook signature— webhook-эндпоинт требует валидную Stripe-подпись, replay невозможен.
4. OAuth nonce validation— WorkOS callback проверяет nonce, injection невозможен.
5. Единая проверка модели—model_detailsиrequested_modelпроходят одну и ту же проверку, дублирование поля берёт последнее значение корректно.
6. Connect-RPC вместо raw gRPC— упрощает auditing и мониторинг, грамотный выбор.

10. Выводы и рекомендации

Найденные уязвимости

CURSOR-2025-001

Prototype Pollution

__proto__в JSON вызывает 500 на billing endpoints

CURSOR-2025-002

Active Debug Code

devRawModelSlugпарсится в production

CURSOR-2025-003

Info Disclosure

GetAllowedModelIntentsраскрывает service mesh

CURSOR-2025-004

Improper Input Validation

Subagent fields не валидируются

Рекомендации для Cursor

1. Санитизировать__proto__иconstructorв JSON-парсинге. ИспользоватьObject.create(null)или библиотеку типаsecure-json-parse.
2. УдалитьdevRawModelSlugиз production proto-схемы или как минимум не возвращать имя поля в ошибке.
3. Унифицировать ошибки авторизации—GetAllowedModelIntentsдолжен возвращать generic 404 вместо “Invalid internal service header”.
4. Валидировать все proto-поля— отклонять запросы с неожиданными полями вselected_subagent_models/selected_subagent_model_details.

Инструментарий

Весь research проведён с помощью:

• Python 3+httpx(HTTP/2 клиент)
• Ручная сериализация protobuf(без .proto файлов)
• grep/sedдля анализа минифицированного JS
• SQLite3 для извлечения токенов

Cursor — один из наиболее security-aware AI-продуктов, которые я исследовал. Plan check полностью серверный, JWT не содержит привилегий, protobuf parsing строгий. Тем не менее, prototype pollution и наличие dev-бэкдора в production — это реальные issues, которые стоит исправить.

Если вы делаете SaaS с серверной авторизацией — вот чеклист из этого исследования:

• ✅ Не храните привилегии в JWT
• ✅ Проверяйте план из БД на каждый запрос
• ✅ Используйте строгий proto parsing
• ❌ Не оставляйте dev-поля в production proto
• ❌ Не раскрывайте внутренние имена через ошибки
• ❌ Санитизируйте__proto__в JSON