Google устранил критическую уязвимость максимальной степени опасности в инструментах Gemini CLI — npm‑пакете @google/gemini-cli и GitHub Actions‑воркфлоу google-github-actions/run-gemini-cli. Ошибка позволяла удалённому злоумышленнику выполнять произвольные команды на хостовой системе, на которой запускался агент, ещё до инициализации песочницы.
Критическая уязвимость в Gemini CLI: как атака приводила к RCE
По данным Novee Security, проблема заключалась в том, что Gemini CLI в режиме headless (типичный вариант для CI/CD) автоматически доверял рабочей директории. Инструмент без проверки загружал конфигурацию и переменные окружения из локальной папки .gemini/, не требуя явного подтверждения или механизма песочницы.
В результате злоумышленник мог подготовить репозиторий с злонамеренной конфигурацией агента и подложить его в поток обработки — например, через pull request в публичный репозиторий. При запуске CI‑воркфлоу, использующего Gemini CLI, конфигурация автоматически загружалась, что открывало путь к удалённому выполнению кода (RCE) на машине CI. Уязвимости присвоен максимальный базовый балл CVSS 10.0, хотя отдельного CVE‑идентификатора пока нет.
Особо опасными оказываются сценарии, где CI‑система обрабатывает непроверенный пользовательский контент — форки, внешние contribution, автоматические проверки PR. В таких случаях компрометация билд‑сервера означает риск атак на всю цепочку поставки ПО (supply chain), поскольку скомпрометированный CI может выпускать заражённые артефакты.
Изменения в Gemini CLI: явное доверие папкам и ужесточение —yolo режима
Google уточняет, что основной риск касался сценариев использования Gemini CLI в headless‑режиме. Исправление меняет модель доверия: перед загрузкой конфигураций теперь требуется явно пометить папки как доверенные. Команды разработки и DevOps должны пересмотреть свои GitHub Actions и другие CI‑воркфлоу и либо работать только с гарантированно доверенными директориями, либо вручную настраивать механизм доверия.
Дополнительно компания усилила защиту при использовании параметра —yolo, который включает автоматическое одобрение действий агента. Ранее в этом режиме игнорировались allowlist‑ограничения в файле ~/.gemini/settings.json, и все вызовы инструментов (включая потенциально опасный run_shell_command) выполнялись без запроса подтверждения. Это создавало риск RCE при обработке непроверенных данных, например, GitHub‑issues или пользовательских запросов, подверженных prompt injection.
Начиная с версии Gemini CLI 0.39.1, движок политик теперь оценивает allowlist даже в режиме —yolo. Это позволяет безопаснее использовать автоподтверждение в CI, ограничивая агента строго перечнем разрешённых команд. При этом некоторые существующие пайплайны могут начать «тихо падать», если их allowlist не учитывает все реально используемые инструменты, и их потребуется скорректировать.
Уязвимости в AI‑IDE Cursor: от CVE-2026-26268 до CursorJacking
Sandbox escape через Git‑хуки (CVE-2026-26268)
Одновременно исследователи Novee Security сообщили о высокоопасной уязвимости в AI‑IDE Cursor до версии 2.5 (CVE-2026-26268, CVSS 8.1). Проблема позволяет добиться произвольного выполнения кода на машине разработчика через цепочку prompt injection и особенностей работы Git.
Cursor описывает её как «escape из песочницы через настройки .git». Злоумышленник может подготовить вложенный «голый» репозиторий (bare .git) с вредоносным Git‑хуком (например, pre-commit), который срабатывает автоматически при каждой операции commit в этом контексте. Если AI‑агент внутри Cursor, действуя «от имени пользователя», запускает git checkout или другие рутинные Git‑команды в таком репозитории, вредоносный хук выполняется вне поля зрения и пользователя, и самого агента, но с правами пользователя.
Корневая причина — не ошибка в логике Cursor как такового, а опасное пересечение функциональности Git и автономных действий AI‑агента. Как только агент начинает самостоятельно выполнять Git‑операции в репозитории, который он не контролирует, каждое «обычное» действие может триггерить скрытую цепочку выполнения кода.
CursorJacking: доступ расширений к API‑ключам и токенам
Отдельно исследователи LayerX описали ещё одну уязвимость высокого риска в Cursor (CVSS 8.2), получившую кодовое имя CursorJacking. Проблема заключается в отсутствии жёстких границ доступа между установленными расширениями и локальной базой данных SQLite, где хранится чувствительная информация: API‑ключи, сеансовые токены и другие учётные данные.
По данным LayerX, любое установленное расширение при наличии локального доступа к файловой системе может прочитать эту базу и, соответственно, получить возможность:
- завладеть аккаунтами через токены сессий;
- обратиться к backend‑сервисам Cursor от имени пользователя;
- злоупотреблять платными API, приводя к финансовым потерям;
- похищать данные проектов и историю взаимодействия с AI.
Уязвимость на момент публикации остаётся не исправленной. Разработчики Cursor подчёркивают, что речь идёт о локальном доступе на машине пользователя, где он сам уже установил расширение и выдал ему разрешения. На практике это означает, что любое злонамеренное или скомпрометированное расширение способно извлечь ценную информацию не только из Cursor, но и из других приложений, использующих локальные хранилища.
Эти инциденты подчёркивают ключевой тренд: AI‑инструменты для разработки и CI/CD становятся новым приоритетным вектором атак. Там, где ИИ получает право автоматически запускать команды, работать с Git и управлять секретами, ошибка в модели доверия или настройках может быстро превратиться в полноценный канал для RCE и атак на цепочку поставки. Организациям стоит пересмотреть политику безопасности для AI‑агентов: ограничивать набор доступных инструментов, жёстко контролировать работу с непроверенным кодом и репозиториями, минимизировать хранение секретов на локальных машинах и устанавливать только проверенные расширения и интеграции.
