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 при отсутствии явной фильтрации и исключения файлов отправил в облачную конечную точку xAI все локальные документы с крайне чувствительной информацией (SSH-ключи, база данных менеджера паролей, фотографии, видео) целиком.
A Green Being заявил, что причиной этой приватной катастрофы стало то, что по неосторожности он запустил инструмент Grok Build в домашнем каталоге. CyberSatoshi ответил на это: «Тебе ещё хуже, чем мне — ты прямо у себя в домашнем каталоге запустил Grok».
Рекомендации по кибербезопасности: категорически не запускать в домашнем каталоге, использовать Sandbox и команды для мониторинга журналов
По рекомендациям специалистов по кибербезопасности для разработчиков, которые уже используют или рассматривают использование инструментов для вспомогательной разработки ИИ вроде Grok Build, следует принять следующие меры защиты:
· Категорически избегать запуска таких ИИ-инструментов в домашнем или корневом каталоге
· Использовать изолированную среду: запускать в отдельном виртуальном окружении (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 (GCP), отметив, что это очень вероятно будет использовано для последующего обучения моделей; тогда он призывал разработчиков сразу проверить локальные файлы журналов Grok.
Как прямо сейчас проверить, были ли данные уже загружены с моего компьютера Grok Build?
Согласно сообщениям, можно посмотреть журналы с помощью следующих команд терминала: cat ~/.grok/logs/unified.json | grep repo_state.upload; если в журнале появляются многочисленные записи repo_state.upload.start и путь загрузки указывает на домашний каталог или корневой каталог, это означает, что данные уже были отправлены в облако; рекомендуется немедленно прекратить использование Grok Build в не изолированной среде и оценить, нужно ли срочно заменить соответствующую чувствительную информацию (SSH-ключи, API-ключи).