Максимальная серьезность устранена.
Google наконец-то прикрыл уязвимость CVSS 10.0, затрагивавшую его инструменты Gemini CLI — в частности, пакет @google/gemini-cli для npm и рабочий процесс google-github-actions/run-gemini-cli в GitHub Actions. Это не просто мелкий баг; речь идет о потенциальном пути для злоумышленников выполнять произвольные команды непосредственно на хост-системах, обходя меры безопасности еще до инициализации песочницы агента. Компания Novee Security, обнаружившая проблему, отметила, что непривилегированный внешний злоумышленник мог подгрузить собственный вредоносный контент в качестве конфигурации Gemini, что приводило к выполнению команд. Это затрагивает версии CLI до 0.39.1 и 0.40.0-preview.3, а также GitHub Action до 0.1.22.
Суть проблемы? В предыдущих версиях Gemini CLI, работающий в CI-средах (так называемый headless mode), автоматически доверял папкам рабочей области. Это означало, что он загружал конфигурацию и переменные окружения без лишних вопросов. Теперь это потенциально катастрофично в сценариях вроде CI-воркфлоу, которые анализируют pull-реквесты, отправленные пользователями. Если злоумышленник мог внедрить специально сформированную конфигурацию в недоверенную папку, он мог фактически превратить ваши CI/CD-конвейеры в стартовые площадки для атак на цепочку поставок. Классический случай избыточного доверия к неявным контекстам.
Исправление от Google требует явного доверия к папкам перед чтением их конфигурационных файлов. Они предлагают пользователям два пути: если ваш воркфлоу работает с доверенными входами от коллег, установите GEMINI_TRUST_WORKSPACE: 'true'. Если же он обрабатывает недоверенные входы, рекомендуется следовать рекомендациям Google по усилению безопасности рабочих процессов и установить соответствующую переменную окружения. Также была усилена система разрешенных инструментов в режиме --yolo, предотвращая сценарии, когда недоверенные входы могли привести к выполнению кода через инъекцию промптов, обходя списки разрешенных инструментов. Это изменение означает, что некоторые рабочие процессы, полагавшиеся на старое поведение, могут перестать работать и потребуют обновления их списков разрешенных инструментов.
Загадка выполнения кода в Cursor
Но это еще не все. Раскрытие информации об уязвимости Gemini CLI совпадает с новостями о критической уязвимости в IDE Cursor с поддержкой ИИ. До версии 2.5 (CVE-2026-26268, CVSS 8.1) Cursor страдал от побега из песочницы через конфигурации .git. Эксплойт позволял злонамеренному агенту установить вредоносный Git-хук внутри bare-репозитория. Каждая операция коммита в таком контексте затем инициировала бы этот хук, приводя к выполнению произвольного кода без участия пользователя. Представьте: вы клонируете публичный репозиторий, открываете его в Cursor, просите «объяснить кодовую базу», и тут – бац – ваш компьютер скомпрометирован, потому что ИИ-агент автономно навигировал к вредоносному Git-хуку. Это подчеркивает более глубокую проблему: ИИ-агенты, выполняющие Git-операции с репозиториями, которые они не полностью контролируют.
«Коренная причина заключается не в недостатке основной логики продукта Cursor, а скорее в следствии взаимодействия функций Git, которое становится эксплуатируемым в тот момент, когда ИИ-агент начинает автономно выполнять операции Git внутри репозитория, который он не контролирует».
Почему это важно для разработчиков?
Это не просто вопрос Google или Cursor; это суровое напоминание для каждого разработчика и организации, полагающейся на инструменты с поддержкой ИИ в своих процессах разработки. Легкость, с которой эти инструменты интегрируются в сложные рабочие процессы, такие как CI/CD, создает новые поверхности для атак. Автоматическое доверие к содержимому репозиториев, особенно в автоматизированных конвейерах, обрабатывающих внешние входные данные, — это уязвимость, ожидающая своего часа. Рынок инструментов для разработки с использованием ИИ переживает бум, и по мере того, как эти инструменты становятся мощнее и интегрированнее, их потенциальное влияние на безопасность — как положительное, так и отрицательное — растет экспоненциально. Скорость инноваций здесь часто опережает усиление мер безопасности, а такие инциденты — это болезненный процесс наверстывания.
Исторически мы видели похожие закономерности с ростом пакетных менеджеров, таких как npm и PyPI. Каждое новшество, упрощающее разработку, также вносит потенциальные векторы для широкомасштабных компромиссов, если ими не управлять с учетом приоритета безопасности. Уязвимости Gemini CLI и Cursor — лишь последние итерации этой продолжающейся проблемы кибербезопасности. Движение в сторону большей автоматизации и интеграции ИИ в процессы разработки требует пропорционального увеличения бдительности в отношении того, как эти инструменты взаимодействуют с нижележащими системами и внешними источниками данных. Доверие должно быть заслуженным, а не предполагаемым, особенно когда на кону выполнение кода.
Тот факт, что уязвимость CVSS 10.0 может существовать в широко используемом инструменте, таком как Gemini CLI, даже если она ограничена определенными режимами, вызывает тревогу. Это подчеркивает продолжающуюся борьбу за обеспечение безопасности цепочки поставок программного обеспечения, особенно когда ИИ играет все более активную роль. Разработчикам необходимо быть предельно осведомленными о разрешениях и уровнях доверия, предоставляемых этим ИИ-агентам в их средах. Это новый рубеж в области безопасности, и уроки, извлеченные из прошлых уязвимостей, актуальны как никогда.
🧬 Связанные инсайты
- Читать далее: UK Cyber Council запускает титул Associate Cyber Pro [Решение проблемы нехватки кадров?]
- Читать далее: [2026] Microsoft Patch Tuesday в апреле: исправлено 167 уязвимостей, 2 уязвимости нулевого дня
Часто задаваемые вопросы
Что позволяет делать уязвимость Gemini CLI злоумышленникам?
Она позволяет злоумышленникам выполнять произвольные команды на хост-системах, обманом заставляя инструмент загружать вредоносные файлы конфигурации и обходя защиту песочницы.
Как работает уязвимость Cursor?
Она использует взаимодействие функций Git, в частности вредоносные Git-хуки внутри репозитория, для достижения выполнения кода, когда ИИ-агент выполняет Git-операции.
Затронут ли меня, если я не использую Gemini CLI в headless-режиме?
Google заявляет, что уязвимость Gemini CLI ограничена рабочими процессами, использующими инструмент в headless-режиме. Однако бдительность всегда рекомендуется.
