Інструменти з ШІ для розробників стрімко входять у стандартний стек команд, але разом із комфортом вони приносять і нові ризики. Дослідники Check Point виявили три серйозні уразливості в ІІ‑асистенті Claude Code, які дозволяли зловмиснику виконувати довільний код на машині розробника та викрадати API‑ключі лише через відкриття підготовленого репозиторію.
Конфігурація Claude Code як новий шар атаки на ланцюжок постачання ПЗ
Claude Code зберігає налаштування проєкту в репозиторії у файлі .claude/settings.json. Через нього команда ділиться спільними параметрами: доступом до зовнішніх сервісів, hook‑скриптами, MCP‑серверами (Model Context Protocol) тощо. Така модель зручна для спільної роботи, але фактично формує ще один рівень software supply chain: будь‑яка особа з правом коміту може непомітно змінити конфігурацію й розповсюдити шкідливі налаштування серед усіх колег.
Традиційно основний фокус безпеки для розробників — це залежності, сторонні бібліотеки та запуск неперевірених скриптів. У випадку Claude Code небезпечним стає вже сам факт відкриття репозиторію. ІІ‑асистент за замовчуванням довіряє конфігураційному файлу поруч із кодом, що й дозволило дослідникам продемонструвати кілька практичних сценаріїв атак без додаткових дій з боку користувача.
Уразливість 1: довільне виконання коду через hooks (CVSS 8,7)
Перша уразливість (оцінка 8,7 за CVSS, без присвоєного CVE) стосувалася механізму hooks — користувацьких shell‑команд, які Claude Code автоматично запускає на певних етапах роботи з проєктом. Ці команди задавалися в конфігурації, а інструмент не вимагав у користувача підтвердження перед їхнім виконанням.
У результаті було достатньо клонувати та відкрити репозиторій із шкідливим hook, щоб довільний код одразу виконався на машині розробника. В демо‑сценарії запускалося стороннє застосування, але на практиці це міг бути, наприклад, reverse shell для віддаленого доступу до системи жертви. Проблему усунули у версії Claude Code 1.0.87, випущеній у серпні 2025 року, де посилили контроль за виконанням користувацьких команд.
Уразливість 2: обхід механізмів довіри через MCP‑сервери (CVE-2025-59536, CVSS 8,7)
Друга помилка, що отримала ідентифікатор CVE-2025-59536 і також оцінена в 8,7 за CVSS, була пов’язана з MCP‑серверами (Model Context Protocol) — каналом взаємодії Claude Code із зовнішніми інструментами й сервісами. Після встановлення першого патча дослідники виявили, що дві конфігураційні опції дозволяють автоматично схвалювати будь‑які MCP‑сервери, повністю обходячи діалоги підтвердження довіри.
Критичність полягала в тому, що шкідливий MCP‑сервер міг активуватись уже на етапі запуску Claude Code, до появи вікна підтвердження довіри до проєкту. Це відкривало можливість непомітно виконувати команди, отримувати доступ до даних або відправляти їх на сторонні ресурси. Уразливість була усунена у версії 1.0.111, випущеній у вересні 2025 року.
Уразливість 3: перенаправлення ANTHROPIC_BASE_URL і крадіжка API‑ключів (CVE-2026-21852)
Третя уразливість, зареєстрована як CVE-2026-21852 з оцінкою 5,3 за CVSS, зачіпала обробку змінної оточення ANTHROPIC_BASE_URL. Цей параметр визначає endpoint, до якого Claude Code звертається для роботи з API. Дослідники показали, що значення ANTHROPIC_BASE_URL можна перевизначити через конфігурацію проєкту, спрямовуючи весь трафік асистента через проксі‑сервер, контрольований зловмисником.
Під час аналізу перехопленого трафіку з’ясувалося, що в кожному запиті Claude Code передавав API‑ключ у відкритому вигляді. Ба більше, запити надсилались ще до того, як користувач бачив діалог довіри до проєкту, що робило витік повністю автоматичним. Отриманий ключ давав можливість працювати з усіма файлами у робочому просторі Claude Code через API: завантажувати, видаляти або модифікувати їх. Виправлення було включено до релізу 2.0.65 у січні 2026 року.
Як уразливості ІІ‑асистентів змінюють модель загроз для розробки
Цей кейс наочно демонструє: ІІ‑асистенти для розробників стають самостійною поверхнею атаки. На відміну від класичних IDE, подібні інструменти одночасно мають доступ до вихідного коду, файлової системи, мережевих ресурсів та секретів (API‑ключі, токени, облікові дані). Тому просте відкриття незнайомого репозиторію в Claude Code може призвести до виконання коду, компрометації секретів або несанкціонованого доступу до файлів.
Рекомендації з кібербезпеки для команд розробки
Перевіряйте конфігурації проєктів. Перед використанням .claude/settings.json уважно аналізуйте його вміст, особливо у сторонніх чи відкритих репозиторіях. Звертайте увагу на hooks, налаштування MCP‑серверів та змінні оточення, що впливають на маршрутизацію трафіку.
Обмежуйте привілеї API‑ключів. Використовуйте принцип найменших прав, виділяйте окремі ключі для розробки, встановлюйте ліміти, вмикайте механізми швидкого відкликання та регулярної ротації. Зберігайте ключі в секрет‑менеджерах, а не в репозиторіях.
Ізолюйте середовище ІІ‑асистентів. Запускайте Claude Code та інші інструменти з ШІ в окремих профілях, контейнерах або sandbox‑оточеннях із мінімально необхідними файловими та мережевими правами, щоб знизити потенційні наслідки компрометації.
Оперативно оновлюйте інструменти. Підтримуйте Claude Code у версії не нижче 2.0.65, стежте за бюлетенями безпеки вендора та вмикайте журналювання дій асистента для подальшого аналізу інцидентів.
Навчайте розробників. Формуйте у команди розуміння, що конфігураційні файли ІІ‑асистентів — це критичний елемент безпеки. Пояснюйте ризики автоматичного виконання команд, роботи з MCP‑серверами та відкриття недовірених репозиторіїв.
Історія з уразливостями Claude Code показує, що конфігурації ІІ‑асистентів, механізми довіри та API‑ключі стають такими ж важливими активами, як і вихідний код. Компаніям варто вже зараз переглянути свої моделі загроз, впровадити контроль за ІІ‑інструментами та регулярний аудит конфігурацій. Чим раніше організації адаптують практики безпеки під реалії ІІ‑орієнтованої розробки, тим менше шансів, що наступна атака на ланцюжок постачання ПЗ пройде непоміченою.
