Обнаружение этих учётных данных необязательно свидетельствует о дыре в безопасности, поскольку Supabase устроена так, что раскрывает клиенту определённые ключи; реальная угроза таится в конфигурации бэкенда, на который они указывают.

Supabase — это популярная опенсорсная альтернатива Firebase, предоставляющая базы данных PostgreSQL с REST API. Она стала особенно популярна в написанных вайб-кодингом приложениях из-за простоты настройки. При правильном конфигурировании с Row Level Security (RLS) публичный ключ API можно безопасно раскрывать — он применяется в качестве идентификатора проекта. Однако без политик RLS этот ключ предоставляет полный доступ к базе данных любому, кто его знает.

В реализации Moltbook эта критичная линия защиты отсутствовала.

При помощи обнаруженного ключа API мы проверили, используются ли рекомендуемые меры безопасности. Мы попытались напрямую отправить запрос к REST API, который должен был вернуть пустой массив или ошибку авторизации в случае активного RLS.

curl
ehxbxtjliybbloantpwq.supabase.co/rest/v1/agents?select=name,api\_key&limit=3" -H «apikey: sb_publishable_4ZaiilhgPir-2ns8Hxg5Tw_JqZU_G6-»

Но база данных ответила точно так, как будто мы были администратором. Она сразу же вернула конфиденциальные токены аутентификации, в том числе и ключи API самых популярных ИИ-агентов платформы.

Так мы подтвердили возможность неаутентифицированного доступа к учётным данным пользователей, позволяющего выдать себя за любого пользователя платформы.

При помощи сообщений об ошибках Supabase PostgREST мы составили список дополнительных таблиц. Запросы несуществующих имён таблиц возвращали подсказки, позволявшие воссоздать истинную схему.

curl «ehxbxtjliybbloantpwq.supabase.co/rest/v1/users» -H «apikey: sb_publishable_4ZaiilhgPir-2ns8Hxg5Tw_JqZU_G6-»

При помощи этой техники в сочетании с интроспекцией GraphQL мы исследовали полную схему базы данных и нашли примерно 4,75 миллиона открытых записей.

Конфиденциальные данные из базы данных Moltbook

1. Ключи API и токены аутентификации ИИ-агентов

В таблице agents находились учётные данные аутентификации каждого зарегистрированного в базе данных агента

{

«name»: «KingMolt»,

«id»: «ee7e81d9-f512-41ac-bb25-975249b867f9»,

«api_key»: «moltbook_sk_AGqY...hBQ»,

«claim_token»: «moltbook_claim_6gNa...8-z»,

«verification_code»: «claw-8RQT»,

«karma»: 502223,

«follower_count»: 18

}

Каждая запись агента содержала:

— api_key — полный токен аутентификации, позволяющий целиком захватить аккаунт.

— claim_token — токен, используемый для подтверждения владения агентом.

— verification_code — код, использованный при регистрации агента.

При помощи этих учётных данных нападающий мог бы выдать себя за любого агента на платформе: публиковать контент, отправлять сообщения и общаться от лица этого агента. Это относится и к аккаунтам с высокой кармой, а также к агентам хорошо известных личностей. По сути, любой аккаунт Moltbook можно было похитить одним вызовом API.

2. Адреса электронной почты и идентификационные данные пользователей

Таблица owners содержала личную информацию о 17 тысячах пользователей

curl «ehxbxtjliybbloantpwq.supabase.co/rest/v1/owners?select=email,x\_handle,x\_name&email=neq.null&limit=5» -H «apikey: sb_publishable_4ZaiilhgPir-2ns8Hxg5Tw_JqZU_G6-»

Кроме того, благодаря запросам к конечной точке GraphQL мы обнаружили новую таблицу observers, содержащую 29631 дополнительный почтовый адрес — это были регистрации раннего доступа ещё не выпущенного продукта Moltbook «Build Apps for AI Agents».

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

3. Личные сообщения и утечки учётных данных сторонних лиц

В таблице agent_messages обнаружилось 4060 личных бесед между агентами.

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

Общение между агентами. Один агент, помогая другому, сливает ему личные ключи своего владельца.

4. Доступ на запись — изменение опубликованных постов

Наряду с доступом на чтение мы подтвердили и полный доступ на запись. Даже после внесения первого исправления, заблокировавшего доступ чтения конфиденциальных таблиц, доступ на запись публичных таблиц оставался открытым. Мы протестировали его и смогли успешно изменить посты на платформе.

curl -X PATCH «ehxbxtjliybbloantpwq.supabase.co/rest/v1/posts?id=eq.74b073fd-37db-4a32-a9e1-c7652e5c0d59» -H «apikey: sb_publishable_4ZaiilhgPir-2ns8Hxg5Tw_JqZU_G6-» -H «Content-Type: application/json» -d '{«title»:"@galnagli — responsible disclosure test",«content»:"@galnagli — responsible disclosure test"}'

Это доказывает, что любой неаутентифицированный пользователь мог:

— Редактировать любой пост на платформе.

— Инъецировать зловредный контент или промпты.

— Дефейсить весь веб-сайт.

— Манипулировать контентом, потребляемым тысячами ИИ-агентов.

Это вызывает вопросы о целостности всего контента платформы (постов, голосов и кармы) до закрытия дыры.

Мы снова уведомили команду разработчиков о необходимости ограничений на запись в политиках RLS.

После подтверждения исправления я больше не мог редактировать оригинал поста, потому что доступ на запись был заблокирован. Несколько часов спустя команда Moltbook удалила контент и поблагодарила нас за отчёт.

1. Скорость без стандартных мер безопасности создаёт системный риск

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

2. Метрики количества участников требуют верификации и защиты

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

3. Взлом конфиденциальных данных может распространяться между экосистемами ИИ

Кроме того, подход платформы к конфиденциальности подчёркивает вывод, важный для всей экосистемы. В личных сообщениях пользователи обменивались ключами OpenAI API и другими учётными данными, считая, что они конфиденциальны, но из-за неправильной конфигурации эти сообщения стали доступны публично. Единственной ошибки в конфигурации платформы было достаточно, чтобы раскрыть учётные данные совершенно никак не связанных с ней сервисов; это показывает, насколько взаимосвязанными стали современные ИИ-системы.

4. Доступ на запись не только подвергает риску раскрытия данных, он гораздо серьёзнее

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

5. Совершенствование безопасности — это итеративный процесс

Безопасность (особенно в стремительно развивающихся ИИ-продуктах) редко можно реализовать одномоментно. Мы работали с командой соцсети в течение нескольких этапов устранения проблем, и на каждой итерации обнаруживались новые открытые поверхности атаки: уязвимые таблицы, доступ на запись, ресурсы, которые можно найти при помощи GraphQL. Такое итеративное совершенствование характерно для новых платформ; оно показывает, что безопасность совершенствуется постепенно.

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

ИИ продолжает снижать барьеры в создании ПО: появляется больше разработчиков со смелыми идеями, но без опыта в обеспечении безопасности, выпускающих приложения для реальных пользователей и реальных данных. И это очень мощный концептуальный сдвиг. Трудность в том, что барьер обеспечения безопасности пока не поспевает за снижением барьера сложности разработки.

Решение будет заключаться не в замедлении вайб-кодинга, а в поднятии его на новый уровень. Безопасность должна стать первостепенным фактором, встроенным в процесс ИИ-разработки. ИИ-помощники, генерирующие бэкенды Supabase, могут включать RLS по умолчанию. Платформы развёртывания могут проактивно искать открытые учётные данные и небезопасные конфигурации. Аналогично тому, как ИИ сегодня автоматизирует генерацию кода, он также может автоматизировать обеспечение безопасности и ограничений.

Если сделать всё правильно, то вайб-кодинг не только упростит разработку ПО… но и превратит безопасность ПО в естественный результат, раскрывающий полный потенциал ИИ-инноваций.

Примечание: исследователь безопасности Джеймсон О'Райли тоже обнаружилнеправильную конфигурацию Supabase, о которой сообщил 404 Media. В нашем посте описан наш опыт независимого нахождения этой проблемы и совместной работы с мейнтейнером Moltbook над повышением безопасности.

31 января 2026 года, 21:48 UTC — отправка сообщения мейнтейнеру Moltbook через личные сообщения в X.

31 января 2026 года, 22:06 UTC — отчёт об ошибочной конфигурации Supabase RLS, раскрывающей таблицу agents (ключи API, почтовые адреса).

31 января 2026 года, 23:29 UTC — первое исправление: обеспечение защиты таблиц agents, owners, site_admins.

1 февраля 2026 года, 00:13 UTC — второе исправление: обеспечение защиты таблиц agent_messages, notifications, votes, follows.

1 февраля 2026 года, 00:31 UTC — обнаружена уязвимость доступа на запись через POST (возможность модификации всех постов).

1 февраля 2026 года, 00:44 UTC — третье исправление: доступ на запись заблокирован.

1 февраля 2026 года, 00:50 UTC — обнаружены новые раскрытые таблицы: observers (29 тысяч почтовых адресов), identity_verifications, developer_apps.

1 февраля 2026 года, 01:00 UTC — последнее исправление: все таблицы защищены, уязвимость полностью пропатчена.