База данных Moltbook полностью открыта: 1,5 млн API-ключей агентов, 35 000 адресов электронной почты

Moltbook — это социальная сеть в стиле Reddit, созданная так, что публиковать в ней могут только ИИ-агенты. Её основатель Мэтт Шлихт запустил её 28 января 2026 года и публично заявил в X, что не написал ни единой строки её кода: «У меня было лишь видение технической архитектуры, а ИИ воплотил его в реальность», — цитирует его Wiz. Три дня спустя, 31 января 2026 года, 404 Media сообщила, что любой мог получить контроль над любым ИИ-агентом на сайте. Компания Wiz, независимо обнаружившая ту же ошибку конфигурации, опубликовала техническое описание 2 февраля: жёстко закодированный в клиентском JavaScript Moltbook ключ API Supabase указывал на продакшен-базу данных без Row Level Security, а неаутентифицированный запрос к таблице agents возвращал действующие токены аутентификации агентов платформы, включая самых известных из них. Wiz насчитала 1,5 млн токенов API, 35 000 адресов электронной почты и 4 060 приватных диалогов между агентами, доступных для чтения таким образом, и подтвердила, что также может переписывать опубликованные посты. Архив классифицирует этот эпизод как инцидент с учётными данными критической степени серьёзности с датой 31 января 2026 года с точностью до дня, оценкой достоверности A и зафиксированным реальным ущербом, наряду с остальными своими записями об агентской инфраструктуре в Orca AI Incident Archive.

Ключ никогда не был секретом

Supabase — это хостинговый сервис Postgres с REST API, который Wiz описывает как популярный среди приложений, созданных с помощью вайб-кодинга, потому что его легко настроить. Его publishable key предназначен для размещения в клиентском коде: он идентифицирует проект, а контроль доступа должен обеспечиваться политиками Row Level Security на таблицах за ним. Гал Нагли из Wiz прямо указывает на это в отчёте: раскрытие ключа «не означает автоматически сбой безопасности», и при правильно настроенной RLS «публичный API-ключ безопасно раскрывать — он действует как идентификатор проекта». В реализации Moltbook, пишет Wiz, «эта критическая линия защиты отсутствовала».

Механизм представлял собой бандл. По данным Wiz, production-файл JavaScript по адресу moltbook.com/_next/static/chunks/18e24eafc444b2b9.js содержал как адрес проекта Supabase, ehxbxtjliybbloantpwq.supabase.co, так и ключ, sb_publishable_4ZaiilhgPir-2ns8Hxg5Tw_JqZU_G6-. Затем Wiz отправил запрос к таблице agents с запросом трёх имён и ключей API — запрос, который должен был вернуть пустой массив или ошибку авторизации. Вместо этого он вернул строки, включая токены аутентификации самых популярных агентов платформы. После этого Wiz определил схему с помощью сообщений об ошибках PostgREST и интроспекции GraphQL и насчитал примерно 4,75 млн открытых записей.

В резюме архива говорится, что Moltbook «никогда не включал» Row Level Security, а источники формулируют это менее строго. Ни в одном из них не показана история конфигурации, поэтому документально подтверждено лишь то, что во время проверки RLS не действовала: Wiz обнаружила, что таблицы открыты, а Implicator.ai, передавая слова нашедшего, пишет, что Moltbook «никогда не включал RLS. Или, если включал, никакие политики не были настроены». Ни один из этих источников не устанавливает, была ли настройка никогда не включена или была включена при отсутствии политик, а практический результат один и тот же.

Что на самом деле было в таблицах

Wiz называет таблицы и их содержимое. Таблица agents содержала в каждой строке api_key, который аутентифицировал агента, claim_token, использовавшийся для заявки на владение им, verification_code, выданный при регистрации, а также показатели кармы и числа подписчиков агента. Это не утечка данных, а полноценный набор для захвата аккаунта: с одним из таких ключей запрос может публиковать сообщения, отправлять личные сообщения и иным образом действовать от имени этого агента, и Wiz отмечает, что среди них были аккаунты с высокой кармой и известные персонажные агенты.

Таблица owners содержала личные данные более 17 000 пользователей, включая адреса электронной почты, а также никнейм в X и отображаемое имя каждого агента. Таблица observers, которую Wiz позже обнаружила через конечную точку GraphQL, содержала ещё 29 631 адрес электронной почты, принадлежавший участникам раннего доступа к запланированному продукту Moltbook «Build Apps for AI Agents». Таблица agent_messages содержала 4 060 приватных бесед в личных сообщениях между агентами, хранившихся без шифрования и контроля доступа, и Wiz сообщает, что в некоторых из них были учётные данные третьих сторон в открытом виде, включая ключи OpenAI API, которыми агенты делились друг с другом.

Соотношение между агентами и людьми — это то, что подорвало публичную версию платформы. Wiz сообщает о 1,5 млн зарегистрированных агентов против примерно 17 000 владельцев-людей, около 88 агентов на человека, и объясняет разрыв отсутствием ограничения скорости или проверки личности: любой мог регистрировать агентов в цикле, а человек мог публиковать сообщения как «агент» с помощью простого POST-запроса. Вывод Wiz прямолинеен: «революционная ИИ-соцсеть в основном оказалась людьми, управляющими флотами ботов».

Количество адресов электронной почты не складывается чисто, и Wiz не объясняет почему. В её заголовочной цифре указано 35 000 адресов электронной почты; её собственные подсчёты на уровне таблиц — более 17 000 адресов владельцев и 29 631 адрес наблюдателей, что в сумме даёт примерно 46 600. Оба числа принадлежат Wiz, и в этом материале не установлено, как были получены 35 000 — путём дедупликации по двум таблицам или из снимка, сделанного до того, как была обнаружена таблица наблюдателей.

Записывающая половина экспозиции

Обнаружение не ограничивалось чтением данных. Wiz сообщает, что даже после того, как первый раунд исправлений заблокировал доступ на чтение к конфиденциальным таблицам, доступ на запись к публичным таблицам остался открытым. Компания проверила это, отправив PATCH-запрос к опубликованному посту и заменив его заголовок и текст строкой "@galnagli - responsible disclosure test", а затем убедилась, что изменение видно на сайте. После введения ограничения на запись Wiz больше не могла откатить собственный тестовый пост; команда Moltbook удалила контент через несколько часов, пишет Wiz, и поблагодарила исследователей за отчёт.

Заявленная обеспокоенность Wiz — не вандализм ради самого вандализма. Неаутентифицированный путь записи в посты означает, что любой мог внедрять полезные нагрузки prompt-injection в контент, который читают другие агенты, и Wiz ставит вопрос о целостности постов, голосов и кармы платформы в течение окна уязвимости как открытый, а не измеренный. Ни один источник, прочитанный для этой статьи, не количественно оценивает, сколько контента было изменено или кем.

Три часа и двенадцать минут, четыре отдельных исправления

Хронология раскрытия Wiz начинается в 21:48 UTC 31 января 2026 года с первого контакта с сопровождающим Moltbook через личное сообщение в X и заканчивается в 01:00 UTC 1 февраля, когда последняя из открытых таблиц была защищена. После этого первого контакта в ней фиксируются ещё семь шагов: отчёт в 22:06, первое исправление в 23:29, охватывающее таблицы agents, owners и site_admins, второе в 00:13, охватывающее agent_messages, notifications, votes и follows, обнаружение пути записи в 00:31, третье исправление, закрывшее его, в 00:44, обнаружение таблиц observers, identity_verifications и developer_apps в 00:50 и окончательное исправление в 01:00.

Эта хронология — сильнейший аргумент против самой простой версии этой истории. Implicator.ai описывает исправление двумя SQL-запросами — там написано, что «исправление требовало двух SQL-запросов. Их не существовало», и в резюме архива используется та же формулировка «две строки SQL». Основное исправление для уязвимости чтения, вероятно, было именно таким малым: включить RLS и добавить политики на таблицы. Но собственные записи Wiz показывают четыре исправления за три часа, вторую и отдельную брешь в доступе на запись, которую исправление чтения не закрыло, и ещё три таблицы — включая 29 631 адрес наблюдателей — которые всплыли только после первых двух раундов. Заключительный урок Wiz состоит в том, что она «работала с командой через несколько раундов устранения, причём каждая итерация выявляла дополнительные открытые поверхности». Версия с двумя строками описывает изменение конфигурации, а не устранение.

Два открытия и одно расхождение в записях

Обнаружение обычно приписывают Джеймисону О'Райли, основавшему австралийскую компанию по безопасности Dvuln и продемонстрировавшему этот захват изданию 404 Media; Implicator.ai сообщает, что 404 Media подтвердила эту возможность, обновив собственный аккаунт О'Райли в Moltbook с его разрешения. Публикация Wiz принадлежит Галу Нагли и содержит в конце примечание, приписывающее заслугу О'Райли: «Исследователь безопасности Джеймсон О'Райли также обнаружил лежащую в основе ошибку конфигурации Supabase, о которой сообщила 404 Media». Далее в примечании говорится, что публикация Wiz описывает независимое обнаружение той же проблемы.

Сводка архива описывает обоих как исследователей Wiz. В собственной публикации Wiz это не так: там Нагли указан как автор, а О'Рейли описан как независимый исследователь, о находке которого сообщило 404 Media, а Implicator.ai относит О'Рейли к Dvuln. Написание имени тоже разнится в источниках — Wiz пишет «Jameson», тогда как на собственном сайте Dvuln основатель указан как «Jamieson», — и в этом материале использовано написание, принятое на этом сайте. Бесспорно лишь то, что одна и та же ошибка конфигурации была независимо обнаружена дважды в течение нескольких дней.

Рассказ о реакции различается в зависимости от источника, и это различие стоит сообщить, а не разрешать. По версии O'Reilly, переданной Implicator.ai, он напрямую обратился к Schlicht и предложил помочь исправить уязвимость; ответ был: «Я просто отдам всё ИИ. Так что присылайте мне всё, что у вас есть». Согласно этой версии, затем прошли целые сутки без последующих действий, а Schlicht не ответил на запрос 404 Media о комментарии. Wiz, связавшись с сопровождающим отдельно, фиксирует свою заявку, поданную в 22:06 UTC, и последнее из четырёх исправлений в 01:00 UTC — через три часа двенадцать минут после первого контакта. Эти две хронологии идут по разным каналам, и ни один источник не говорит, побудил ли один другой; обе могут быть точными.

Что подтверждают материалы дела, а что — нет

Установленные факты — это конфигурация, классы данных, два независимых обнаружения, последовательность исправлений и соотношение людей и агентов на платформе. Всё в этом списке взято из первичного технического отчёта Wiz или из публикаций, основанных на рассказе обнаружившего, и оба источника сходятся в описании механизма.

Что не установлено, начинается с предшествующего доступа. Wiz заявляет, что все данные, к которым был получен доступ в ходе его исследования и проверки исправления, были удалены, но это ничего не говорит о ком-либо ещё. Implicator.ai прямо обозначает пробел: никто не может сказать, нашёл ли кто-то базу данных раньше O'Reilly, и сколько из постов, циркулировавших в течение вирусной недели платформы, были подлинным выводом агента, а сколько — результатом использования украденного ключа. Ни один источник, прочитанный для этой статьи, не сообщает о подтверждённом неправомерном использовании каких-либо раскрытых учётных данных, и ни один не приводит количества фактически захваченных аккаунтов. Флаг real_harm в архиве имеет значение true, потому что персональные данные и действующие сторонние учётные данные действительно могли прочитать все, а не потому, что был зафиксирован конкретный случай неправомерного использования.

Количество агентов тоже расходится, причём это расхождение отражает рост платформы, а не факты утечки. Implicator.ai, писавший 1 февраля со слов обнаружившего, описывает «более 32 000» зарегистрированных агентов — в материале также говорится, что сайт перешагнул отметку в 37 000 в первую неделю, — и 1,49 млн раскрытых записей. Wiz, изучив вопрос 2 февраля, насчитал 1,5 млн агентов и примерно 4,75 млн записей. В сводке архива указано, что в итоге платформа накопила 1,7 млн зарегистрированных агентов и почти 7 млн комментариев; этот материал не проверял независимо ни один из этих итоговых показателей. Единственное, что подтверждают все версии, — это общая картина: агентов гораздо больше, чем людей, и нет механизма, который мог бы отличить одно от другого.

Что изменилось и что настройка не исправила

Изменения носят узкий и задокументированный характер: политики RLS на чувствительных таблицах, ограничение записи на публичных таблицах, удаление тестового поста исследователей и, по данным Wiz, платформа, которая была полностью пропатчена к 01:00 UTC 1 февраля. Ни в одном из источников, прочитанных для этой статьи, не упоминается, что Moltbook добавил ограничение частоты запросов, проверку идентичности агентов или аудит контента, написанного в течение этого окна. Рекомендации Wiz нацелены на инструменты, а не на платформу: AI-ассистенты, генерирующие бэкенды Supabase, могли бы включать RLS по умолчанию, а платформы развертывания могли бы сканировать на предмет раскрытых учетных данных и небезопасных конфигураций.

То, что переживёт SQL, — это посылка, которую сделала видимой база данных. Сеть, чьим преимуществом было то, что публиковать могли только ИИ-агенты, не имела способа проверить, что агент — это агент, и её слой учётных данных был единственным, что отделяло человека со скриптом от каждой личности на сайте. Вот почему эта запись значится как веха, а не как рутинная ошибка конфигурации: утечка была обычной, а то, что она обнажила, — аутентифицированный слой идентификации для автономных агентов, — нет.