Grok Build від xAI завантажував на хмару цілі Git-репозиторії та секрети — що сталося

12 липня 2026 року незалежний дослідник безпеки cereblab опублікував аналіз на рівні мережевого трафіку інструменту Grok Build CLI версії 0.2.93 від xAI. Аналіз показав, що інструмент завантажував набагато більше даних, ніж було необхідно, зокрема цілі Git-репозиторії, повну історію комітів та незашифровані секрети з .env-файлів до хмарного сховища Google Cloud Storage . Завантаження відбувалися навіть тоді, коли користувачі відмовлялися від збору даних, а xAI виправив проблему лише на стороні сервера, залишивши клієнт без змін, що означає, що будь-які вже передані конфіденційні дані неможливо відкликати .

Що виявили дослідники

Grok Build мав два окремі канали передачі даних, і жоден з них не обмежувався лише даними, необхідними для завдання з кодування.

Канал запитів до моделі на перший погляд працював очікувано: коли Grok Build зчитував файл для завдання, вміст файлу надсилався на сервери xAI у складі запиту до моделі. Однак конфіденційні дані, такі як API-ключі та паролі до баз даних з .env-файлів, передавалися у відкритому тексті без жодного маскування .

Фоновий канал зберігання виявився набагато тривожнішим відкриттям. Незалежно від того, які файли відкривав агент, CLI пакував весь Git-репозиторій — включно з повною історією комітів — і завантажував його на Google Cloud Storage у відро з назвою grok-code-session-trace через кінцеву точку

POST /v1/save-session

Дослідник безпеки Hari незалежно підтвердив це за допомогою зворотного інжинірингу, опублікувавши повідомлення про те, що Grok Build завантажував цілі каталоги користувачів без явного дозволу . В одному тесті з репозиторієм об'ємом 11,2 ГіБ щонайменше 5,1 ГіБ даних було завантажено через фоновий канал, тоді як для виконання завдання з кодування потрібно було лише близько 192 КБ . Завантаження містили повну історію Git, секрети з .env та всі файли репозиторію — не лише ту частину, яка була потрібна для завдання .

Як відреагували Ілон Маск та xAI

Ілон Маск публічно підтвердив проблему на платформі X, почавши свою відповідь зі слова "True" . Він пообіцяв: "Як запобіжний захід, усі дані користувачів, раніше завантажені до SpaceXAI, будуть повністю та ретельно видалені. Жодного байта не залишиться" .

xAI випустив публічну заяву, в якій наголосив, що серйозно ставиться до конфіденційності користувачів, і зазначив, що корпоративні клієнти, які використовують Zero Data Retention (ZDR), ніколи не мали свого коду або даних для навчання . Компанія також впровадила зміни на стороні сервера, вимкнувши кінцеву точку /v1/save-session, що зупинило фонове завантаження репозиторіїв . Станом на 13 липня 2026 року завантаження припинилися .

Залишкові проблеми, незважаючи на виправлення

Хоча відповідь xAI зупинила активний витік даних, кілька проблем залишаються невирішеними.

1. Виправлення було на стороні сервера, а не клієнта. Дослідник зазначив, що сам клієнт Grok Build CLI (версія 0.2.93) ніколи не оновлювався — xAI просто вимкнув кінцеву точку прийому на своїх серверах . Це означає, що клієнтський код все ще має можливість завантажувати цілі репозиторії; така поведінка може відновитися, якщо кінцеву точку знову ввімкнуть.

2. Відмова від збору даних xAI не зупинила завантаження. Дослідник перевірив команду "режиму конфіденційності" або відмови від зберігання даних і виявив, що вона не запобігла фоновому завантаженню всього репозиторію . Дослідник прямо заявив: "Команда конфіденційності xAI не виправила це" . Натомість прихований серверний прапорець під назвою disable_codebase_upload було встановлено на значення true .

3. Відсутність публічних повідомлень про зміни. xAI вимкнув функцію завантаження, не повідомивши користувачів і не додавши запису до журналу змін .

4. Відсутність підтвердження фактичного видалення даних. Хоча Маск пообіцяв видалення, на момент публікації звітів не було незалежного підтвердження того, що раніше завантажені дані користувачів у відрі grok-code-session-trace було очищено .

5. Дані, які вже витекли, неможливо відкликати. Будь-які конфіденційні облікові дані, власний код або секрети, передані до виправлення, вже зберігалися на хмарній інфраструктурі xAI . Дослідник перехопив завантаження, зміг клонувати Git-пакет і відновити файли, які агенту було прямо заборонено читати .

Підсумок ключових фактів

Що це означає для розробників

Інцидент з Grok Build підкреслює зростаючий ризик для розробників, які використовують AI-асистентів для кодування. Багато таких інструментів надсилають код на хмарні сервери для обробки, але обсяг того, що передається та зберігається, часто є непрозорим. У цьому випадку інструмент надсилав набагато більше, ніж було потрібно — і робив це навіть тоді, коли користувачі явно намагалися цьому запобігти.

Доки xAI не випустить оновлення клієнта та не надасть незалежного підтвердження видалення даних, розробники, які використовували Grok Build, повинні припускати, що будь-які облікові дані, власний код або конфіденційна інформація, присутні в їхніх репозиторіях, могли бути передані на хмарну інфраструктуру xAI.