3 августа 2026 года один из наших клиентов Metabase Cloud сообщил о создании ключа API в нерабочее время.
Мы провели расследование и заметили аномальный шаблон доступа: один и тот же IP-адрес создал ключ API на двух разных экземплярах клиентов, используя одну и ту же последовательность конечных точек. Мы определили начальную конечную точку, с которой началась цепочка атак, и установили сетевую блокировку для всего нашего парка клиентских экземпляров.
В ходе расследования мы установили, что создавался действительный идентификатор сессии, и с помощью обратной разработки выявили неизвестную уязвимость («нулевого дня»), которая позволяла злоумышленнику генерировать активную сессию. Мы создали патч и немедленно применили его к нашим облачным экземплярам клиентов.
Мы проанализировали наши логи и начали исследовать влияние на клиентов. Мы также привлекли стороннюю компанию по реагированию на инциденты и криминалистике.
Мы начали подготовку публичного релиза и в процессе расследования обнаружили еще несколько производных уязвимостей, основанных на том же принципе, и добавили исправления для них в релиз.
Мы упаковали эти исправления и выпустили исправленные версии 6 августа.
Кто пострадал?
Все установки Metabase версий 0.58 и выше были уязвимы.
Менее 3% наших облачных клиентов были скомпрометированы в результате этой уязвимости до выхода патча, так же как и некоторые пользователи open-source версий и клиенты, использующие self-hosted экземпляры Metabase с публичным доступом.
В чем заключалась неизвестная уязвимость?
Уязвимость представляла собой цепочку атак, использующую особенности взаимодействия 4 уровней нашей кодовой базы.
Отправной точкой атаки был наш URL для сброса пароля (/reset-password).
Этот URL принимал тело запроса:
Первым звеном в этой цепочке был тот факт, что наши аннотации типов API в Malli не были «закрытыми»; аннотации типов проверяли только наличие обязательных ключей и их соответствие типу. Дополнительные ключи не вызывали ошибку валидации.
Вторым шагом стало то, что рефакторинг системы аутентификации от 11 ноября 2025 года изменил обработку параметров: вместо передачи только токена и пароля стало передаваться всё тело запроса.
Третий шаг заключается в том, что при входе в поток аутентификации, если указан ID пользователя, запись этого пользователя ищется по ID с помощью нашего ORM, Toucan2. Это выполнялось функцией select-one в Toucan2, где «ID» пользователя было значением, переданным из URL сброса пароля.
Наконец, Toucan2 использовал HoneySql для генерации запроса.
Если предикат фильтра включал «сырой» (raw) ключ, HoneySql обрабатывал его как сырой SQL, вставляя без изменений.
Отправляя тело запроса вида
злоумышленник мог выполнить SQL-инъекцию.
Сама атака использовала это для вставки записи в нашу таблицу сессий с известным user_id 1 (первый пользователь в экземпляре Metabase, всегда изначально создаваемый как «администратор»), а затем использовала эту сессию для просмотра данных и создания ключа API, позволяющего массово скачивать таблицы.
Какова была сигнатура этой атаки?
Хотя эта атака может быть выполнена разными способами, шаблон, который мы наблюдали, был таким:
Что мы исправили?
Мы защитились от этой атаки на трех разных уровнях:
- Передавали только поля токена и пароля из обработчика API
Передавали только поля токена и пароля из обработчика API
- Отклоняли потенциально опасные ключи при входе в поток аутентификации
Отклоняли потенциально опасные ключи при входе в поток аутентификации
- Вызывали исключения при обнаружении неожиданных ключей в служебных макросах
Вызывали исключения при обнаружении неожиданных ключей в служебных макросах
Что мы делаем, чтобы предотвратить это в будущем?
Учитывая сложность этой атаки, требуемые знания нашей кодовой базы и поведение двух вложенных зависимостей (Toucan2 и Honey SQL), мы полагаем, что для этой атаки требовались значительные возможности LLM.
Ранние запросы использовали строки user-agent, которые намекают на обход ограничений LLM: «metabase-postgres-admin-session-lab-verifier/1», «metabase-read-only-sqli-verifier/1», после чего происходила ротация между 25 вариантами, похожими на «Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/146.0.0.0» «Safari/537.36 Edg/146.0.0.0 Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:149.0) Gecko/20100101 Firefox/149.0».
Учитывая чрезвычайно быстрый рост возможностей LLM в анализе кода и их способность выстраивать глубокие цепочки атак, мы усиливаем защиту Metabase на всех уровнях, а не ограничиваемся исправлением только этой одной уязвимости.
Это усиление защиты происходит на многих уровнях нашей кодовой базы, включая:
- Предотвращение создания сессий и других конфиденциальных значений в БД через SQL-инъекции без внеполосного ключа шифрования;
- Валидация схемы по умолчанию (закрытая) на всех конечных точках;
- Добавление дополнительной проверки данных;
- Унификация разрозненных проверок прав доступа;
- Предотвращение SQL-инъекций в Toucan через HoneySQL raw;
- Усиление нашего процессора запросов MBQL для запрета выполнения сырого SQL без экранирования;
- Блокировка потенциальных путей SSRF;
- Увеличение разделения кэш-ключей между пользователями;
- Усиление песочницы и имитации подключения к БД; и
- многое другое.
Мы выпустили первую партию этих мер по усилению защиты в версии 63.13 и выпустим еще один релиз с улучшениями безопасности, прежде чем вернемся к нашему обычному графику разработки.
Мы также сотрудничаем с внешними исследователями (еще одна благодарность Ophion Security и red team Anthropic) и продолжаем сканировать нашу кодовую базу с помощью большего разнообразия моделей и подходов.