Уязвимости Gemini CLI и Cursor: как AI-инструменты превратились в дыры безопасности

Google исправила критическую уязвимость в Gemini CLI с максимально возможной оценкой по шкале CVSS — 10.0. Баг затрагивает версии пакета @google/gemini-cli ниже 0.40.0-preview.3 и GitHub Actions workflow google-github-actions/run-gemini-cli ниже 0.1.22. CVE-идентификатор уязвимости не присвоен. Об этом на прошлой неделе опубликовала предупреждение сама Google, а в среду детальный разбор механики атаки выпустила компания Novee Security.
Уязвимости Gemini CLI и Cursor: как AI-инструменты превратились в дыры безопасности
Изображение носит иллюстративный характер

Проблема в том, как Gemini CLI ведёт себя в headless-режиме, то есть при работе в CI/CD-конвейерах без участия пользователя. В старых версиях инструмент автоматически доверял рабочим папкам и загружал оттуда конфигурации и переменные окружения. Злоумышленник мог подсунуть в директорию .gemini/ вредоносный конфигурационный файл через, например, пул-реквест в публичный репозиторий. Gemini CLI загружал этот файл ещё до инициализации песочницы, что давало атакующему прямое выполнение произвольного кода на хосте без каких-либо привилегий. CI/CD-конвейер превращался в готовый вектор атаки на цепочку поставок.
Патч меняет логику доверия: теперь папки нужно явно помечать как доверенные до того, как Gemini CLI получит доступ к их содержимому. Для рабочих процессов с доверенными входными данными в workflow нужно задать переменную GEMINI_TRUST_WORKSPACE: 'true'. Если входные данные могут быть ненадёжными — следует изучить официальные рекомендации Google по ужесточению конфигурации.
Параллельно в версии 0.39.1 исправлена отдельная проблема в режиме автоматического подтверждения --yolo. Раньше этот режим полностью игнорировал списки разрешённых инструментов из файла ~/.gemini/settings.json и без каких-либо запросов выполнял абсолютно все вызовы, включая run_shell_command. Достаточно было инжектировать вредоносный промпт через, например, текст GitHub-issue, чтобы получить выполнение кода. После патча механизм политик Gemini CLI учитывает allowlist даже в --yolo-режиме. Побочный эффект: рабочие процессы, которые рассчитывали на старое поведение, могут молча сломаться, пока их конфигурации не будут обновлены.
AI-редактор Cursor страдает от двух отдельных уязвимостей. Первую — с оценкой CVSS 8.1 и идентификатором CVE-2026-26268 — тоже обнаружила Novee Security. В феврале 2026 года Cursor выпустил предупреждение об уязвимости, затрагивающей все версии до 2.5. Атака строится на цепочке: вредоносный markdown-файл содержит инструкцию для AI-агента перейти к bare-репозиторию, выполнить git checkout ветки master, в процессе чего агент самостоятельно настраивает репозиторий с заранее подготовленным Git-хуком. Когда checkout происходит, хук — post-checkout или pre-commit — выполняется тихо, за пределами reasoning-цепочки агента и совершенно незаметно для пользователя.
Исследователь Novee Security Ассаф Левкович особо отметил, что это не баг в логике самого Cursor: атака эксплуатирует взаимодействие стандартных возможностей Git в ситуации, когда AI-агент автономно выполняет git-операции в неконтролируемом репозитории. Именно автономность агента и неограниченный доступ к файловой системе создают условия для sandbox escape.
Вторая уязвимость Cursor называется CursorJacking, её нашли исследователи LayerX, оценка CVSS — 8.2. Патча на неё до сих пор нет. Суть: Cursor не разграничивает доступ между установленными расширениями и локальной базой данных SQLite, где хранятся API-ключи, сессионные токены и учётные данные. Любое расширение с доступом к локальной файловой системе способно извлечь эти данные. Исследователь LayerX Рой Пац перечислил возможные последствия: перехват аккаунтов, утечка данных, несанкционированное использование API, финансовые потери и кража данных через имперсонацию пользователя.
Позиция Cursor по CursorJacking сводится к тому, что доступ ограничен локальной машиной, где пользователь сам установил расширение и выдал ему разрешения, а значит, нужно устанавливать только проверенные расширения. Это стандартная отговорка, которая, впрочем, не объясняет, почему чувствительные данные вообще доступны расширениям без дополнительного контроля доступа.
Обе истории вместе дают неприятную картину: инструменты, которые созданы помогать разработчикам и автоматизировать рутину, сами становятся точками входа для атак. Встроенная автономность AI-агентов, их способность выполнять команды без явного подтверждения и тесная интеграция с инфраструктурой — это ровно те характеристики, которые делают эти инструменты полезными и одновременно опасными при ненадлежащей изоляции.


Новое на сайте

20327Кости прерий: как истребление бизонов породило целую индустрию — и сама себя же уничтожила 20326Кто и зачем взламывает серверы Ollama и ComfyUI ради ключей от AWS? 20325Как злоумышленники спрятали командный сервер внутри блокчейна и почему его невозможно... 20324Брюссель заставляет Android делиться секретами с чужими ИИ-помощниками 20323WordPress: как два бага слились в одну критическую дыру, которую назвали wp2shell 20322Как китайские хакеры обманули DigiCert и украли сертификаты для подписи кода? 20321Что скрывается за уязвимостью, которую агентство США внесло в список активно используемых... 20320Автономные системы наступают быстрее, чем инфраструктура для управления ими: кто выиграет... 20319Почему в OpenSSL нашли дыру, съедающую память серверов, но не дали ей даже номер CVE? 20317SonicWall SMA 1000: как два бага превратили VPN-шлюз в бэкдор для атакующих 20316Может ли уязвимость в клиенте Zoom для Windows открыть доступ к чужому аккаунту без... 20315TELEPUZ: новый вредонос на C, который научился прятаться в Telegram, Steam и блокчейне... 20314Дома из дёрна: как исландцы триста лет прятались от холода под слоем земли и травы 20313Как один токен от чужого сервиса мог впустить злоумышленника в чужой аккаунт n8n?
Ссылка