С июля по сентябрь 2026 года японские организации столкнулись с резким ростом утечек персональных данных через веб‑системы: по данным Macnica, уже за три квартала зафиксировано 119 инцидентов, тогда как за весь 2025 год было 84, а отдельные случаи (Park24, Monogatari) приводят к компрометации десятков миллионов записей; JPCERT/CC связывает волну с массовым злоупотреблением мобильными и внутренними API, а также с эксплуатацией критической уязвимости CVE-2026-72898 в Metabase, поэтому операторам веб‑сервисов, мобильных приложений и BI‑систем необходимо срочно инвентаризировать доступные из интернета API и обновить Metabase до минимально безопасных версий.
Технические детали инцидентов
Масштаб и хронология
Анализ центра Macnica показывает, что к 6 октября 2026 года публично раскрыто 119 инцидентов в Японии, где данные утекли через веб‑системы, при этом:
- 62 инцидента в 2024 году;
- 84 в 2025 году;
- 119 уже в 2026 году, из них 81 — с июля, что указывает на резкий скачок.
Серия не включает вымогательское программное обеспечение и иные «классические» атаки — речь именно о компрометации веб‑и API‑слоев. JPCERT/CC в своём уведомлении от 8 октября 2026 года (официальный алерт JPCERT/CC) фиксирует вал инцидентов «один за другим» в районе сентября.
Характерные крупные случаи:
- Park24 (Times Car): несанкционированный доступ к данным около 6,6 млн аккаунтов сервиса каршеринга, а отдельно — утечка изображений удостоверений личности примерно 1,6 млн пользователей.
- Monogatari (приложение Yakiniku King): утечка 10 788 963 записей из системы участников.
Причина в этих инцидентах официально ещё расследуется, но они по масштабу и профилю укладываются в серию, описанную Macnica.
Основные векторы атак на API
JPCERT/CC выделяет несколько повторяющихся моделей злоупотребления API‑интерфейсами мобильных и веб‑приложений:
- Анализ мобильного приложения и извлечение из него:
- списка API‑endpoint’ов бэкенда;
- ключей и токенов API, вшитых в приложение.
Злоумышленник затем формирует прямые HTTP‑запросы к этим endpoint’ам, иногда так, чтобы трафик напоминал нормальное использование, что усложняет детектирование.
- Доступ к «внутренним» функциям API, не представленным в интерфейсе приложения:
- изменение уровней привилегий пользователя;
- создание несанкционированных учётных записей;
- тестирование поведения сервера при модификации заголовков, удалении токена или отправке повреждённого маркера аутентификации;
- поиск деталей аккаунтов через «слепую» NoSQL‑инъекцию.
- Повторное использование украденных API‑ключей, компрометированных в других системах.
Типичные ошибки на стороне защищаемых систем:
- endpoint’ы возвращают больше данных, чем нужно конкретной операции;
- API выполняет операции с чрезмерными привилегиями;
- функциональность для участников доступна анонимным пользователям;
- ошибки в логике авторизации и управлении сессиями.
Macnica дополнительно подчёркивает, что секретные ключи API и пароли баз данных, встроенные в клиентское приложение или код в браузере, легко извлекаются даже из минимизированного или обфусцированного кода, поэтому такие практики недопустимы (разбор Macnica).
Эксплуатация CVE-2026-72898 в Metabase
Отдельный вектор — атаки на Metabase, популярный BI‑инструмент, через критическую SQL‑инъекцию CVE-2026-72898 с оценкой CVSS 10.0 (запись NVD по CVE-2026-72898). Уязвимость:
- эксплуатируема без учётной записи;
- позволяет проводить SQL‑инъекцию в собственную базу Metabase;
- даёт возможность получить права администратора Metabase;
- оттуда атакующий может выгрузить сохранённые учётные данные подключённых баз данных и получить доступ к их содержимому.
Metabase сообщила об инциденте в своей облачной службе 6 августа 2026 года и выпустила обновление безопасности (обновление от 6 августа). Позже компания опубликовала расширенный перечень минимально безопасных версий для разных веток продукта (security‑релиз от 12 августа) и дополнительное предупреждение по ряду критических проблем (security advisory GitHub).
Ключевой признак эксплуатации CVE-2026-72898 по данным Metabase:
- в логах сервера фиксируется
POST /api/session/reset_passwordс кодом ответа 400; - затем следует
GET /api/user/currentс кодом 200.
Временная мера для тех, кто не может немедленно обновиться, — блокировать endpoint /api/session/reset_password на уровне веб‑сервера или межсетевого экрана приложений. Metabase прямо описывает это как временный обходной путь, а не полноценное решение.
IOC от JPCERT/CC и Macnica
JPCERT/CC опубликовал набор показателей компрометации (актуальны как ориентир, а не как «чёрный список», так как адреса могли быть повторно использованы легитимным трафиком).
Подозрительная активность API (около сентября 2026)
- IP: 3.112.252[.]14
- IP: 54.95.112[.]6
- IP: 69.10.51[.]162
- IP: 172.86.91[.]7
- IP: 210.149.87[.]120
- User-Agent:
curl/7.88.1 - User-Agent:
python-requests/2.34.2 - User-Agent:
Mozilla/5.0 ... Chrome/126.0 Safari/537.36
Эксплуатация Metabase (начало августа — начало сентября 2026)
- IP: 213.163.202[.]171
- IP: 221.216.140[.]49
- IP: 221.216.140[.]129
- User-Agent:
python-requests/2.33.1 - User-Agent:
Metabase-GHSA-vwf4/2.0
Macnica отдельно выделяет IP 210.149.87[.]120 и 69.10.51[.]162 как приоритетные для проверки, подчёркивая, что наличие обращений с этих адресов — лишь повод к углублённому анализу логов, а не прямое доказательство атаки.
Контекст угроз и география
Хотя JPCERT/CC и Macnica не связывают серию утечек с конкретной группировкой, прослеживается единый стиль: атакующие массово «зондируют» любые публичные веб‑системы, где могут оказаться персональные данные, и используют любую найденную слабость в аутентификации, авторизации, конфигурации или известных уязвимостях.
Список пострадавших систем выходит далеко за рамки интернет‑магазинов: членские сервисы, бизнес‑системы, клиентская поддержка, библиотечные каталоги, системы бронирования туристических поездов. Macnica также нашла 99 аналогичных инцидентов в 13 странах и регионах вне Японии (в том числе 30 — в Южной Корее, 11 — во Франции и 8 — в Польше), что говорит о глобальном характере подхода атакующих.
Применение автоматизации (вплоть до ИИ‑подбора уязвимостей) пока не подтверждено: в логах нет прямых признаков такого использования, но охват и интенсивность сканирования делают полностью ручной подход маловероятным — это важный сигнал для пересмотра диапазона тестируемых сценариев при аудите безопасности.
Оценка воздействия для организаций
Наивысшему риску подвержены:
- организации с массовыми потребительскими мобильными приложениями (банкинг, ритейл, транспорт, развлечения);
- сервисы с моделью «учётная запись + бонусы/подписка», где хранятся контактные данные, история заказов, номера карт лояльности;
- компании, использующие Metabase, особенно в режиме прямого доступа в интернет к панели и API;
- структуры, где BI‑платформы имеют доступ к производственным базам данных с персональной информацией.
Потенциальные последствия бездействия:
- массовые утечки персональных данных (имена, контакты, документы, поведенческие данные);
- регуляторные санкции со стороны комиссий по защите данных (в Японии — Комиссия по защите персональной информации, уже выпустившая свой алерт и методические указания: alert PPC, guidance PPC);
- компрометация бизнес‑аналитики и производственных БД через Metabase как единый точку входа;
- репутационный ущерб и рост затрат на уведомление пострадавших и последующие иски.
Практические рекомендации по защите
1. Немедленные меры для владельцев Metabase
- Определить все инстансы Metabase (on‑premise и в cloud), доступные из интернета.
- Сравнить текущие версии с минимально безопасными, опубликованными Metabase (перечень безопасных релизов), и немедленно обновиться как минимум до рекомендованного релиза.
- До обновления — заблокировать
/api/session/reset_passwordизвне как временное смягчение риска. - Проверить логи на наличие последовательности:
POST /api/session/reset_password→ HTTP 400;GET /api/user/current→ HTTP 200.
При обнаружении такой цепочки следует считать сервер скомпрометированным.
- Для инстансов, где endpoint был доступен из интернета, после обновления выполнить полный цикл восстановления, рекомендованный Metabase:
- аннулировать все активные пользовательские сессии;
- перепроверить и удалить подозрительные API‑ключи;
- аудировать учётные записи администраторов;
- сменить пароли и ключи всех подключённых баз данных;
- проанализировать логи хранилищ данных на предмет аномальных запросов;
- изучить историю запросов в Metabase на предмет неожиданных выборок.
2. Укрепление API и мобильных бэкендов
Рекомендации JPCERT/CC и OWASP API Security (OWASP API Security Top 10) задают базовый минимум контроля:
- ограничение числа запросов в единицу времени (rate limiting), особенно для:
- аутентификации и входа;
- сброса пароля;
- отправки SMS и почтовых уведомлений;
- поиска и других ресурсоёмких функций.
- жёсткая авторизация на каждом endpoint’е, включая «непубличные»:
- проверка прав не только для пользовательских, но и для административных операций;
- раздельная проверка допустимых HTTP‑методов.
- принцип минимально необходимых прав:
- ограничение областей данных для каждого ключа и токена;
- отказ от «универсальных» ключей со всеми правами.
- строкий срок жизни API‑токенов и возможность оперативного отзыва при утечке.
- запрет на хранение секретов (ключи API, пароли БД) в мобильных приложениях и фронтенд‑коде.
- включение административных функций в периметр регулярного тестирования уязвимостей.
3. Мониторинг и ретроспективный анализ логов
На ближайший месяц имеет смысл выполнить углублённый разбор журналов веб‑серверов, API‑шлюзов и БД за период не менее 30 дней, обращая внимание на:
- аномально большой объём API‑запросов с одного IP‑адреса;
- всплески ответов 403, 404, 503 и других ошибок;
- обращения к несуществующим endpoint’ам и файлам;
- существенный рост общего числа запросов при статусе 200 (злоупотребление «легитимными» вызовами);
- использование административных функций с нетипичных IP‑адресов;
- рост нагрузки на базу данных и пул сессий, совпадающий с аномалиями в трафике;
- увеличение числа попыток входа в систему.
Ключевой вывод для пострадавших и потенциально уязвимых организаций: необходима срочная проверка версий Metabase и изоляция его от прямого доступа из интернета, одновременное внедрение строгих контролей доступа и ограничений частоты для всех API‑endpoint’ов, а также ретроспективный анализ логов минимум за месяц по указанным признакам, с последующим перевыпуском компрометированных ключей и паролей.
