Metabase закрыла критическую уязвимость с оценкой 10 из 10 по CVSS, которую уже использовали в реальных атаках. Для тех, кто держит BI-платформу в проде, это неприятный сценарий не про «еще один баг», а про удаленный захват админки, доступ к подключенным базам и возможную утечку данных по цепочке.
Проблема в том, что уязвимость Metabase позволяет неавторизованному удаленному атакующему внедрять SQL-команды в application database самой платформы, сообщает Dark Reading. Дальше схема выглядит слишком знакомо для 2026 года: получив права администратора на инстанс, злоумышленник может менять конфигурацию, вытаскивать сохраненные учетные данные от подключенных БД, читать доступные через них данные и экспортировать их наружу. Отдельный штрих, который делает историю еще неприятнее: у бага пока нет CVE, хотя по тяжести это полноценный «критикал» с максимальной оценкой.
Под удар попали ветки Metabase, начиная с 0.58.0. В advisory перечислены уязвимые диапазоны: от 0.58.0 до 0.58.23, от 0.59.0 до 0.59.20, от 0.60.0 до 0.60.16, от 0.61.0 до 0.61.10, от 0.62.0 до 0.62.8 и от 0.63.0 до 0.63.3. Безопасными названы релизы 0.58.24, 0.59.21, 0.60.17, 0.61.11, 0.62.9 и 0.63.5. Для клиентов Metabase Cloud это хотя бы частично хорошая новость: вендор заявил, что облачные инстансы обновлены автоматически. А вот для self-hosted история куда менее комфортная. Если endpoint /api/session/reset_password торчит в публичный интернет, инстанс остается пригодным для атаки, пока администратор сам не обновится или хотя бы временно не закроет этот маршрут.
Здесь важен не только сам баг, но и его рабочий радиус. Metabase редко живет в вакууме: обычно это фронт к нескольким SQL-базам, отчетам, дашбордам и иногда к данным, которые потом разъезжаются по продуктам, командам и внешним клиентам. Именно поэтому Dark Reading и эксперты SANS говорят о широком blast radius. Если BI-слой скомпрометирован, attacker получает не просто одну систему, а удобную точку входа в данные бизнеса. Johannes Ullrich из SANS Internet Storm Center отдельно отметил, что exploit требует доступности уязвимого API endpoint. По его словам, Metabase можно ставить как Docker-контейнер или как standalone Java-приложение, и в обоих вариантах API обычно выставляется в сеть на порт 3000. Дальше все упирается в то, насколько аккуратно настроены firewall и proxy. На практике, как несложно догадаться, парольный reset endpoint редко кто прячет точечно.
История уже вышла за пределы самого Metabase. В материале Dark Reading приведены как минимум два пострадавших кейса. Стартап n8n 8 августа раскрыл, что атакующий получил 136 клиентских записей с именами и email-адресами пользователей self-hosted и n8n Cloud. Компания также сообщила, что в пяти записях были bcrypt-хэши паролей облачных аккаунтов, а еще у 25 аккаунтов пароли оказались сохранены в открытом виде из-за ранее исправленной уязвимости. n8n заявила, что доступ к этим аккаунтам маловероятен, но владельцев 25 записей все равно уведомили отдельно. Еще один пример — Kilo Code, стартап с open-source AI coding agents. По его данным, компрометация через Metabase Cloud произошла 2 августа и длилась около четырех часов; за это время атакующий получил доступ к части клиентских записей с именами, email-адресами и другой информацией. Позже, 9 августа, Kilo добавила, что инцидент затронул и ее Slackbot: у небольшой части пользователей оказались раскрыты Slack access tokens, которые компания затем принудительно инвалидировала.
Для российских и вообще русскоязычных IT-команд в этой новости нет экзотики, зато есть неприятная практичность. Многие компании по-прежнему воспринимают BI как «вспомогательный интерфейс к данным», а не как систему с доступом к секретам и критичному периметру. Но если платформа хранит credentials к production- или warehouse-базам, строит отчеты по клиентским данным и дает доступ бизнес-пользователям, то компрометация такого слоя быстро становится не задачей администратора Metabase, а задачей всей команды безопасности, платформы и продукта. После апдейта вендор рекомендует не ограничиваться патчем: отозвать активные пользовательские сессии, проверить API-ключи, просмотреть администраторские аккаунты на неожиданные изменения, сменить credentials для подключенных баз, изучить логи data warehouse и историю запросов. Отдельный индикатор компрометации — последовательность запросов: сначала POST /api/session/reset_password с кодом 400, затем GET /api/user/current с кодом 200.
Есть и более широкий контекст. SQL-инъекция давно должна была остаться в презентациях про нулевые, но продолжает возвращаться в инфраструктуру, где разработчики балансируют между поддержкой нескольких движков, скоростью релизов и сложной логикой запросов. В случае Metabase это особенно показательно: платформа работает как универсальный мост к разным БД, и цена ошибки здесь выше, чем у рядового веб-сервиса. Поэтому главный вопрос после этого инцидента не в том, сколько еще компаний пропустили обновление, а в том, сколько команд до сих пор считают аналитический слой «не самым приоритетным» сегментом периметра. Для атакующих это, похоже, уже давно не так. Подробности описаны в материале .