Попередження для розробників: Grok Build завантажив весь домашній каталог до xAI — SSH-ключі та сховища паролів повністю розкриті

13 липня розробник A Green Being у дописі на X опублікував скріншот журналу unified.json, звинувативши, що інструмент Grok Build, який належить xAI, що керується Маском, архівує весь каталог користувача та завантажує його на сервери xAI; витік містить його персональний SSH-ключ, базу даних менеджера паролів, особисті файли, фотографії та відео — «витекло абсолютно все».

Докази зі скріншота журналу A Green Being

(Джерело: A Green Being)

Згідно зі скріншотом єдиного журналу unified.json, яким A Green Being поділився на X, система справді викликала численні запити repo_state.upload.start, а шлях для завантаження безпосередньо вказував на домашній каталог цього користувача (/home/usuario); це означає, що Grok Build без явної фільтрації та виключення файлів передає всі локальні документи із надзвичайно чутливою інформацією (SSH-ключі, базу даних менеджера паролів, фотографії, відео) цілком у хмарну кінцеву точку xAI.

A Green Being заявляє, що саме через те, що він необережно запустив інструмент Grok Build у своєму домашньому каталозі (Home Directory), і сталася ця приватницька катастрофа. CyberSatoshi відповів: «Ти ще гірший за мене — ти просто запускав Grok у своєму домашньому каталозі».

Рекомендації з кібербезпеки: обов’язково уникати запуску з домашнього каталогу, використовувати Sandbox і команди моніторингу журналів

Відповідно до порад фахівців із кібербезпеки, для розробників, які вже користувалися або планують використовувати Grok Build та подібні AI-інструменти для допоміжної розробки, мають бути вжиті такі заходи захисту:

· У жодному разі не запускати такі AI-інструменти в домашньому каталозі або кореневому каталозі

· Використовувати ізольоване середовище: запускати в окремому віртуальному середовищі (Sandbox), контейнері Docker або в спеціальному обмеженому обліковому записі користувача

· Активно моніторити журнали: через команди терміналу (cat ~/.grok/logs/unified.json | grep repo_state.upload) перевіряти, чи немає аномальної поведінки завантаження даних

· Негайно перевірити історичні журнали: якщо Grok Build уже використовувався, потрібно одразу переглянути файли журналів Grok на локальному пристрої й підтвердити, чи відбулося витікання даних

Поширені запитання

Чому Grok Build завантажує весь домашній каталог, а не лише код проєкту?

Згідно з повідомленнями, під час фонових операцій завантаження Grok Build не вистачало належного механізму виключення файлів (наприклад, автоматичного ігнорування .gitignore або системних прихованих файлів); коли користувач запускає інструмент у домашньому каталозі, базовий дизайн інструменту сприймає домашній каталог як повне «середовище контексту» та завантажує його повністю, а не лише програмні файли. Це подвійна помилка — недолік у дизайні інструменту та неправильне місце запуску з боку користувача.

Які саме ризики раніше конкретно вказав CyberSatoshi?

Згідно з повідомленнями, раніше CyberSatoshi (@XBToshi) попереджав, що Grok Build у фоновому режимі мовчки завантажує весь репозиторій (Repository), історію Git, а також приховані файли .env, які містять конфіденційні дані, зокрема API-ключі, і все це відправляє на Google Cloud Platform (GCP), та зазначав, що це дуже ймовірно буде використано для подальшого тренування моделей; тоді він уже закликав розробників негайно перевірити файли журналів Grok на локальному пристрої.

Як одразу перевірити, чи на моєму комп’ютері вже є дані, які Grok Build завантажив?

Згідно з повідомленнями, можна переглянути журнали за допомогою таких команд терміналу: cat ~/.grok/logs/unified.json | grep repo_state.upload; якщо в журналі з’являється багато записів repo_state.upload.start і шлях для завантаження вказує на домашній каталог або кореневий каталог, це означає, що дані вже було передано в хмару; рекомендується негайно зупинити використання Grok Build у неізольованому середовищі та оцінити, чи потребують негайної заміни відповідні чутливі дані (SSH-ключі, API-ключі).