Grok Build выдал данные 35 000 приложений из-за секрета в поддомене

Представьте: вы за десять минут собрали внутренний дашборд с помощью AI-агента, нажали «поделиться» и отправили ссылку коллеге. Адрес длинный, со случайными словами, так что угадать его невозможно. А потом выясняется, что его видит любой, кто умеет пользоваться публичной базой DNS-запросов. По данным исследователей из Claroc, именно так вышло с Grok Build, vibe-кодинг агентом SpaceXSI (так теперь называется объединённая SpaceX и xAI).

Что именно сломалось

Идея у схемы здравая. Она называется capability-based access control: знание URL равно праву доступа. Нужно лишь, чтобы адрес нельзя было угадать или найти. Три случайных слова дают около 38 бит энтропии, то есть миллиарды комбинаций. Google делает похоже в Docs, но случайная строка стоит в пути, после домена.

Grok Build поместил случайные слова слева от домена, в поддомен: cinder-crane-sand-frost.grok.me. А имена поддоменов утекают. Когда кто-то впервые запрашивает IP-адрес нового хоста, запись оседает в публичных базах passive DNS. Остаётся поискать всё, что заканчивается на grok.me. Подбирать ничего не нужно, достаточно прочитать готовый список. Путь из URL в DNS-запрос не попадает, поэтому у ссылок Google этот трюк не работает.

Claroc нашла 43 601 ссылку на grok.me. Больше 35 000 из них, почти 95%, открывали приложение вместе со всеми данными. Среди найденного: 3 784 медосмотра рабочих перуанской стройкомпании, список из 3 565 сотрудников больницы, таблица с 22 техниками Tesla с продуктивностью и бонусами, около 4 000 заказов автоперевозчика с ценами и маржой. Нашлись и 24 приложения самой SpaceXSI: план онбординга сейлза с пометкой confidential и карта из 594 клиентских аккаунтов.

Дефолт против реальности

По тестам Асафа Апрозпера, CTO Claroc, Grok Build по умолчанию ставит доступ «Anyone with the link». Чтобы закрыть приложение, пользователь должен сам выбрать «приглашённые» или «только вы». Представитель Cursor (его недавно купила SpaceXSI) заверил, что приложения приватны по умолчанию. Тесты Claroc это опровергают. На дальнейшие вопросы Ars Technica ответа не было.

Хронология тоже показательна. Claroc сообщила об утечке в воскресенье, ответа не получила и тегнула в X Маска и менеджера Grok. Ссылки на 24 внутренних приложения исчезли только через несколько часов после запроса журналистов. Остальные данные оставались доступными.

Проблема шире одного Grok. Lovable, Bolt и Replit тоже выдают каждому приложению собственный адрес, так что DNS-следы у них те же. Просто в Grok нашлось больше всего чувствительных корпоративных данных. Meta Muse недавно приостановила функцию шаринга после похожей утечки. Правильно это устроено у Claude artifacts, ChatGPT share и Gemini share: секрет лежит в пути, и DNS его не видит.

Что делать на практике

Если вы или ваша команда собирали что-то в Grok Build, сначала зайдите в настройки всех приложений и смените доступ на «приглашённые» или «только вы». То же стоит проверить в Lovable, Bolt и Replit. Помните, что ссылка, однажды ушедшая в passive DNS, уже могла попасть в чужие базы. Если внутри были персональные данные или коммерческие предложения, закройте доступ и оцените, нужно ли уведомлять людей и клиентов.

Для тех, кто строит платформы с шаринговыми ссылками, урок такой. Секрет-capability нельзя класть в имя хоста, только в путь или в токен после домена. Для внутренних инструментов лучше вообще включать авторизацию, а публичный доступ делать осознанным выбором, а не значением по умолчанию.

Есть и оговорки. Цифры взяты из исследования Claroc, независимой проверки пока нет. Публичное приложение не обязательно содержит чувствительные данные, а многие из 35 000 могут быть просто демо. SpaceXSI не объяснила, как внутренние документы оказались в открытых приложениях и будет ли она уведомлять клиентов. Но главный вывод от этого не меняется: vibe-кодинг ускоряет выкатку, а вместе с ней и ошибки в настройках доступа. Привычка «сгенерировал и расшарил» должна включать проверку, кто именно сможет открыть ссылку.