AI‑інструменти для розробки та CI/CD усе активніше інтегруються в життєвий цикл ПЗ, але паралельно перетворюються на привабливу ціль для атак. Нещодавні знахідки Novee Security та LayerX показують, як помилки в моделі довіри Gemini CLI й AI‑IDE Cursor відкривають шлях до віддаленого виконання коду (RCE), компрометації CI‑інфраструктури та викрадення секретів.
Критична уразливість Gemini CLI в headless‑режимі CI/CD
Google усунув критичну уразливість максимальної небезпеки у Gemini CLI (npm‑пакет @google/gemini-cli та GitHub Actions‑воркфлоу google-github-actions/run-gemini-cli). Помилка дозволяла віддаленому зловмиснику виконувати довільні команди на хості, де запускався агент, ще до ініціалізації будь‑якої песочниці. Базовий бал загрози оцінено в CVSS 10.0, хоча окремий CVE поки не призначено.
За даними Novee Security, коренева проблема полягала в тому, що Gemini CLI у headless‑режимі, типовому для CI/CD, автоматично довіряв поточній робочій директорії. Інструмент без перевірки завантажував конфігурацію агента та змінні середовища з локальної папки .gemini/, не вимагаючи явного підтвердження чи механізму sandboxing.
Це відкривало класичний канал атаки на CI/CD: зловмисник міг підготувати репозиторій із шкідливою конфігурацією агента та провести його в пайплайн через pull request, fork або інший потік обробки неперевіреного коду. Під час запуску GitHub Actions чи іншого CI‑воркфлоу, що використовує Gemini CLI, конфігурація з .gemini/ підхоплювалася автоматично, що призводило до віддаленого виконання коду на CI‑сервері.
Найвищий ризик виникав у сценаріях, де CI обробляє неперевірений контент — зовнішні contribution, форки, автоматичні перевірки PR. Компрометація такого build‑сервера створює загрозу supply chain атак: скомпрометований CI може випускати заражені артефакти, підписані легітимною інфраструктурою організації.
Зміни в Gemini CLI: модель довіри до директорій та посилення режиму –yolo
Google уточнює, що основний вектор атаки стосувався саме безголового використання Gemini CLI в CI/CD. Виправлення кардинально змінює модель довіри: тепер перед завантаженням конфігурацій директорію необхідно явно позначити як довірену. Командам розробки та DevOps рекомендується переглянути свої GitHub Actions та інші пайплайни, обмеживши їх роботою лише з гарантовано безпечними папками або налаштувавши явний список довіри.
Додатково Google посилив безпеку при використанні параметра –yolo, який вмикає автоматичне схвалення дій агента. Раніше в цьому режимі ігнорувалися обмеження allowlist у файлі ~/.gemini/settings.json, тому всі інструменти, включно з небезпечним run_shell_command, могли виконуватися без підтвердження. У поєднанні з prompt injection та обробкою неперевірених даних (наприклад, GitHub‑issues чи користувацьких запитів) це створювало прямий ризик RCE.
Починаючи з версії 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‑ключі, сеансові токени та інші облікові дані.
За наявності локального доступу до файлової системи будь‑яке інстальоване розширення може прочитати цю базу й отримати можливість:
- перехопити облікові записи через сеансові токени;
- звертатися до backend‑сервісів Cursor від імені користувача;
- зловживати платними API, створюючи фінансові втрати;
- викрадати дані проєктів і історію взаємодії з AI.
На момент публікації CursorJacking залишається не виправленою. Розробники Cursor наголошують, що йдеться про локальний доступ на машині користувача, де він сам дозволив установку розширення. На практиці це означає, що будь‑яке шкідливе або скомпрометоване розширення здатне витягувати цінні дані не лише з Cursor, а й з інших застосунків, які покладаються на локальні сховища.
У сукупності ці інциденти демонструють, що AI‑інструменти для розробки та CI/CD стають пріоритетним вектором атак. Організаціям варто переглянути політику безпеки щодо AI‑агентів: обмежувати набір доступних інструментів через allowlist, не запускати «–yolo» поруч із неперевіреним кодом, ізолювати CI‑середовища для зовнішніх contribution, мінімізувати локальне зберігання секретів на машинах розробників і встановлювати лише перевірені розширення та інтеграції. Чим раніше ці практики стануть стандартом, тим менше шансів, що чергова зручна AI‑функція перетвориться на критичну точку входу для атак.
