Як Claude Code зливає паролі та API-ключі в публічні репозиторії GitHub

Що сталося

Паролі та API-ключі, які розробники вводили в команди й затверджували в Claude Code, лежать у відкритих репозиторіях GitHub — прочитати їх може будь-хто. Такого висновку дійшла американська компанія з безпеки додатків Apiiro, яка 5 листопада 2026 року опублікувала дослідження про механізм витоку, що вже встиг стати одним із найгучніших кейсів року в темі «AI-агенти та безпека коду».

Суть проблеми — у звичайній, «зручній» опції. Коли користувач обирає «Yes, and don't ask again» («Так, і більше не запитуй»), Claude Code — агент для написання коду від Anthropic — зберігає команду дослівно, разом із секретом, у файл налаштувань проєкту. Якщо цей файл потрапляє в публічний репозиторій, секрет стає доступним усьому світу.

Apiiro знайшла 104 185 публічних копій файлу .claude/settings.local.json у 103 617 репозиторіях GitHub. У 1 122 з них (близько 1,1%) лежить принаймні один справжній секрет. Дослідники не перевіряли, чи всі вони ще робочі, але одна компанія, якій вони повідомили про знахідку, підтвердила: її ключ був активним.

Як секрет опиняється у файлі налаштувань

Механізм простий і лякає саме своєю буденністю. За замовчуванням Claude Code питає дозвіл перед виконанням більшості shell-команд. Розробник просить агента перевірити, чому не працює вхід на staging-сервер, або запустити міграцію бази даних. Агент складає команду, яка несе пароль або токен із конфігурації, — бо без нього команда просто не спрацює.

Якщо користувач обирає «Yes, and don't ask again», Claude Code зберігає затвердження як allow-правило у файлі .claude/settings.local.json всередині проєкту. Далі схожі команди виконуються без зайвих запитань. Ключовий нюанс: коли правило стосується конкретної команди (а не шаблону на кшталт npm test *), у файл зберігається весь рядок — разом із паролем чи токеном у відкритому тексті.

Тобто жодного злого умислу чи «зламу» моделі тут немає. Це штатний потік затвердження дозволів: розробник один раз натискає кнопку «не питай знову», і секрет із робочого процесу опиняється у JSON-файлі проєкту. Дослідники відтворили цю поведінку на останніх моделях — Opus 5.5 і Fable 5.1.

Важливо відрізняти цей витік від раніших уразливостей конфігурації Claude Code, коли зловмисники змінювали налаштування проєкту, щоб викрадати API-ключі. Тут не потрібні ні шкідливий промпт, ні зламаний акаунт: секрет фіксується під час звичайної, легальної роботи — і саме тому проблема така небезпечна. Розробник не робить нічого «неправильного», крім вибору зручної опції.

Масштаб проблеми: цифри дослідження

Якщо говорити про масштаб, то 1 122 файли зі секретами — лише верхівка. У них Apiiro нарахувала 1 379 унікальних секретів: 636 ключів у відомих форматах провайдерів і 743 паролі або токени, що стояли поруч з адресою публічного сервера. Але секрети є не тільки в актуальних версіях файлу.

Розширивши пошук на історію git, спільний файл .claude/settings.json (який команди комітять свідомо) та збережені логи агента, дослідники вийшли на загальну цифру — 2 539 секретів у 1 994 репозиторіях. Старі версії файлу, яких уже немає в поточній гілці, містять ще 734 секрети у 509 репозиторіях. Проблему посилюють форки: 211 форків 74 репозиторіїв несуть ті самі секрети, що й оригінали.

Витік не обмежується GitHub. Серед 31 053 проєктів на Hugging Face Spaces Apiiro знайшла 126 копій файлу, в одній із них — правила з ключем сервісу бази даних і паролем користувача. На GitLab.com із 69 перевірених публічних копій у двох лежав справжній секрет.

Секрети ховаються і в супутніх артефактах агентів. Серед 2 523 збережених транскриптів чату агентів Apiiro виявила секрети у 120 файлах у 87 репозиторіях. У 1 200 файлах пам'яті агентів (MEMORY.md та подібні) секрет знайшли у 9 репозиторіях, а серед 2 095 нотаток про передачу завдань — у 33 файлах. Показово, що третину нотаток із секретами написав сам агент.

Чому вбудований захист не спрацьовує

Claude Code намагається тримати файл подалі від git. Коли агент уперше створює .claude/settings.local.json у git-репозиторії, він додає його до глобального списку виключень git цього користувача. Тобто git на цьому конкретному комп'ютері ігнорує файл у всіх репозиторіях.

Але цей захист, за словами дослідників, живе лише в налаштуваннях git одного користувача на одній машині. Він не спрацьовує, якщо:

• файл уже був закомічений раніше;
• папка стала репозиторієм уже після того, як файл з'явився;
• проєкт клонували на інший комп'ютер;
• файл створили вручну, а не через Claude Code.

Головне: Claude Code ніколи не додає файл до .gitignore самого проєкту, тому захист не «подорожує» разом із репозиторієм і не поширюється на інших учасників команди. У 539 із 1 105 простежених репозиторіїв файл змінював коміт, де Claude зазначено співавтором, — тобто агент нерідко сам комітить цей файл.

Окрема проблема — сканери секретів. Gitleaks позначив лише 564 із 1 122 файлів, TruffleHog — 643, а 215 файлів не помітив жоден із них. Причина в тому, що пароль після PGPASSWORD=, sshpass -p чи mysql -p виглядає для сканера як звичайне слово у звичайній команді — без розпізнаваного формату ключа.

Додатковий ризик — сам файл у відкритому тексті на диску. Зловмисне ПЗ і без того активно «замітає» машини розробників у пошуках облікових даних, як показали нещодавні кейси зі зламаним пакетом LiteLLM і шкідливим розширенням Claude Code у редакторі Cursor. Файл із секретами на ноутбуці стає для такого ПЗ ще однією готовою мішенню.

Що саме витекло: від паролів БД до медичних записів

За даними Apiiro, постраждали 63 організації — переважно софтверні компанії різного розміру. Найсерйозніші кейси вражають:

• власний cloud-ключ рівня адміністратора у вендора бази даних — без обмеження терміну дії, разом з адресою кластера;
• production-пароль бази Azure PostgreSQL у B2B-стартапу;
• production-токен платіжної системи Square;
• пароль власника бази даних застосунку для медичних записів.

Понад третину секретів відкривають прямий доступ до бази даних: 379 паролів БД і 122 ключі Supabase service-role. Ще 103 токени акаунтів Supabase контролюють усі проєкти в обліковому записі. Решта — це 43 SSH-логіни до публічних серверів, 42 токени GitHub, GitLab та npm, 23 ключі AWS і 6 приватних ключів.

Важливо розуміти різницю між «витоком» і «компрометацією». Секрет у публічному репозиторії — це підтверджений витік, який вимагає негайного реагування, але не доказ того, що ним уже скористалися зловмисники. Apiiro не перевіряла валідність усіх ключів і не стверджує, що хтось їх використав.

Як захиститися розробнику: покроковий план

Порядок дій, який рекомендують дослідники, починається з ротації, а не з прибирання. Видалення файлу не скасовує витік — старі версії залишаються в історії git і в форках. Тому:

1. Знайдіть .claude/settings.local.json і .claude/settings.json у своїй організації на GitHub і перевірте історію кожного репозиторію навіть там, де файлу вже немає.
2. Спочатку змініть (ротуйте) кожен пароль, токен і ключ, які файл коли-небудь містив, — і лише потім прибирайте.
3. Припиніть відстежувати локальний файл: git rm --cached .claude/settings.local.json і додайте його до .gitignore самого репозиторію, щоб правило подорожувало з проєктом.
4. Відкрийте файл на своєму комп'ютері — навіть якщо він ніколи не комітився — і видаліть кожне правило, що містить секрет.
5. Не вводьте секрети в команди напряму. Посилайтеся на них як на змінні з менеджера секретів (наприклад, $DB_URL), щоб у правилі зберігалося ім'я змінної, а не сам секрет.
6. Затверджуйте шаблони, як-от Bash(npm run:*), а не конкретні команди.

Окремо варто пам'ятати: файл — це звичайний JSON у папці проєкту. Він може опинитися не лише в git, а й усередині npm-пакета, Docker-образу, zip-архіву чи синхронізованої папки.

Рекомендації для security-команд

Для команд безпеки Apiiro формулює кілька практичних кроків:

• Ставтеся до папок агентів — .claude/, .cursor/, .gemini/, .specstory/ — і до файлів пам'яті агента як до носіїв секретів, нарівні з .env, причому як на ноутбуках, так і в репозиторіях.
• Додайте їх до pre-commit і CI-сканування секретів, включно з історією git. Переконайтеся, що сканер ловить паролі всередині команд (PGPASSWORD=, sshpass -p, mysql -p, заголовки bearer), а не лише ключі відомих форматів.
• Додайте .claude/settings.local.json до шаблонів .gitignore вашої організації.
• У першу чергу перевіряйте облікові дані, поруч із якими стоїть публічний сервер, — саме вони дають реальний доступ.

Висновок

Кейс із Claude Code — нагадування про те, що зручність AI-агентів для коду може дорого коштувати, якщо не вбудувати безпеку в робочі процеси. Проблема тут не в «злій» моделі й не в продуманій атаці: достатньо звичного натискання кнопки «не питай знову», щоб секрет у відкритому тексті опинився в публічному репозиторії.

Показово й те, що про таку поведінку користувачі повідомляли ще в серпні 2025 року (issue №5544 у репозиторії Claude Code), але той звіт автоматично закрили з позначкою «not planned». Apiiro наголошує, що з-поміж 16 порівняних агентів для коду Claude Code — єдиний, хто за замовчуванням зберігає повну затверджену команду у файлі проєкту.

Цей кейс — не поодинокий, а частина ширшого тренду. Упродовж 2026 року дослідники неодноразово фіксували, як AI-агенти для коду ненавмисно «виносять» назовні те, що мало залишатися приватним: від знімків внутрішніх систем до облікових даних. Корінь проблеми щоразу той самий: інструмент зберігає більше, ніж потрібно, а розробник не бачить, що саме потрапляє у файли проєкту.

Головний урок для українських команд і розробників простий: якщо ви користуєтеся AI-агентами для роботи з кодом, перевірте свої репозиторії вже сьогодні. Почніть із ротації секретів — а якщо хочете дізнатися, чи ваші облікові дані вже гуляють відкритою мережею, скористайтеся перевіркою витоків. Тим, хто лише починає будувати культуру безпеки в команді, радимо почати з основ кібербезпеки.