Cursor не съхранява API ключове в защитено хранилище, което означава, че всяко разширение може да има достъп до тях. Cursor знаеше за тази уязвимост, но не я поправи.

Резюме

Изследователи по сигурността на LayerX са установили, че всяко разширение на популярния инструмент за разработка на изкуствен интелект Cursor може да получи достъп до API ключовете и сесийните токени на разработчика, което води до пълно компрометиране на идентификационните данни, без да е необходима никаква намеса или активност от страна на потребителя. 

LayerX откри, че тъй като Cursor не съхранява ключове в защитено хранилище, който и да е Разширението Cursor може да изпълни този достъп. В резултат на това всеки потребител на Cursor е уязвим за кражба на API ключ от злонамерени разширения на Cursor.

Експлоатацията на тази уязвимост може да доведе до излагане на сесийни токени и API ключове, неоторизиран достъп до backend услуги на Cursor и кражба на данни чрез представяне за друг потребител.

LayerX съобщи за тази уязвимост на Cursor. Cursor отговориха, че разпознават проблема, но че е отговорност на потребителя да определи границата на доверие. Към днешна дата този проблем не е отстранен от Cursor.

 

Ключовете на Cursor API се съхраняват в отворена, локална база данни

Cursor, популярна среда за разработка, задвижвана от изкуствен интелект, съдържа уязвимост с висока степен на сериозност за контрол на достъпа (CVSS 8.2), което позволява на всяко инсталирано разширение да има достъп до чувствителни идентификационни данни, съхранявани локално.

За разлика от стандартните практики за сигурност, където тайни данни, като API ключове и сесийни токени, се съхраняват в защитено хранилище (например, ключодържатели на операционната система), Cursor съхранява тези идентификационни данни в локална SQLite база данни:

` ~/Библиотека/Поддръжка на приложения/Курсор/Потребител/globalStorage/state.vscdb `

Важно е да се отбележи, че Cursor не налага граници за контрол на достъпа между разширенията и тази база данни. В резултат на това всяко разширение – независимо от декларираните от него разрешения – може директно да чете от нея и да извлича чувствителни данни.

Това създава мощен примитив за атака: злонамерено или компрометирано разширение Cursor може тихомълком да открадне API ключове и токени за сесия, което позволява поемане на контрол над акаунти, достъп до данни и финансови злоупотреби.

 

Въздействие

Тази уязвимост позволява пълно компрометиране на идентификационни данни без взаимодействие с потребителя (освен инсталиране на разширение), което води до:

  • Излагане на сесийни токени и API ключове
  • Неоторизиран достъп до услугите на Cursor backend
  • Компрометиране на интеграции от трети страни (напр. OpenAI, Anthropic, Google)
  • Представяне под чужда самоличност и достъп до данни

Риск надолу по веригата (пример: кражба на ключ за OpenAI API)

Ако нападател получи ключа на OpenAI API на жертвата, той може:

  • Изпълняване на API повиквания, таксувани на жертвата → финансова загуба
  • Подкани за достъп, довършвания и метаданни → излагане на данни
  • Злоупотреба с API за по-нататъшни атаки или автоматизация
  • Потенциално да се извлече чувствителна информация от предишни взаимодействия

Тъй като тези ключове често предоставят широк достъп, въздействието се простира отвъд самия Cursor и обхваща по-широката екосистема на потребителя, свързана с изкуствен интелект и разработка.

 

Технически преглед

Нека разгледаме реалистичен сценарий на атака от гледна точка на нападателя.

Фигура 1. Поток на експлоатация

Стъпка 1: Подготовка на злонамереното разширение

Атакуващ създава на пръв поглед безобидно разширение Cursor – може би инструмент за продуктивност, тема или помощна програма. То не изисква никакви подозрителни разрешения и изглежда безопасно за инсталиране.

От гледна точка на потребителя, нищо не изглежда необичайно.

Стъпка 2: Потребителят инсталира разширението

Разработчикът инсталира разширението от пазар или хранилище на GitHub.

Има:

  • Без предупреждение
  • Няма подкана за разрешение, свързана с достъп до идентификационни данни
  • Няма индикация за риск

В този момент атакуващият разполага с изпълнение на код в средата на разширението Cursor.

Стъпка 3: Достъп до чувствително хранилище

Cursor съхранява чувствителни данни в локална SQLite база данни, спомената по-горе. Тази база данни съдържа:

  • Токени за сесия
  • API ключове (напр. OpenAI)
  • Други артефакти за удостоверяване

Поради липсващ контрол на достъпа, разширението може директно да отваря и да прави заявки към тази база данни. Не се изискват специални привилегии.

Стъпка 4: Извличане на идентификационни данни

Разширението анализира базата данни и извлича:

  • API ключове
  • Токени за сесия
  • Възможно е кеширана конфигурация или метаданни

Фигура 2. Пример за заявка към база данни от разширение PoC

Тъй като данните се съхраняват в открит текст (или не са достатъчно защитени), извличането им е лесно.

Стъпка 5: Тиха ексфилтрация

Разширението изпраща откраднатите идентификационни данни на контролиран от хакер сървър, което може да се направи с просто извличане. Това се случва тихо:

  • Не се изисква взаимодействие с потребителя
  • Няма видими промени в потребителския интерфейс
  • Няма сигнали

Стъпка 6: След експлоатация

Нападателят вече притежава валидни идентификационни данни.

Защо това е с висока степен на тежест

Тази уязвимост е особено опасна, защото:

  • Не са необходими разрешения
  • Не се изисква взаимодействие с потребителя след инсталирането 
  • Ниска сложност на атаката
  • Високо въздействие върху поверителността

За да подчертаем колко лесно това може да бъде използвано, създадохме Разширение за PoC и демонстрационно видео:

 

Хронология на разкриването:

Въпреки че докладът показва, че разширенията могат да имат достъп до локалната база данни на SQLite, съдържаща идентификационни данни, този достъп е ограничен до локалната машина, където потребителят вече е инсталирал и е предоставил разрешения за разширението. Това представлява същата граница на доверие като всяко друго локално приложение – злонамерени разширения с достъп до локалната файлова система биха могли потенциално да имат достъп до различни хранилища на данни на приложенията.

  • Коригиране на състояниетоНе е фиксирано. Вт, 28 апр. 2026 г. 

Препоръчително отстраняване

За да се справи правилно с този проблем, Курсорът трябва:

  • Приложете строга изолация между разширенията и хранилището за чувствителни идентификационни данни.
  • Чувствителните идентификационни данни трябва да се обработват чрез защитен, криптиран слой за съхранение или ключодържател на системно ниво (напр. ключодържател за macOS, мениджър на идентификационни данни за Windows).