С сентября 2026 года японские организации одна за другой сообщают об утечках персональных данных через веб-системы. Злоумышленники используют мобильные API, внутренние и административные интерфейсы, известные уязвимости, ошибки настройки и системы бизнес-аналитики. JPCERT Coordination Center (JPCERT/CC) в Токио сообщил об этой серии 8 октября 2026 года, отдельно подчеркнув, что речь не идет о программах-вымогателях или других обычных киберинцидентах. Центр не назвал ни нападающих, ни пострадавшие организации и предупредил, что располагает «ограниченной и фрагментарной» информацией: методы атаки могли различаться от случая к случаю. В опубликованном предупреждении приведены индикаторы компрометации и рекомендации, а сам документ может обновляться.
Масштаб роста виден по данным японской компании Macnica. Ее Security Research Center опубликовал анализ 7 октября 2026 года на основе материалов реагирования на инциденты и изучения журналов; JPCERT/CC сослался на эту работу. Macnica насчитала в Японии 62 похожих случая за 2024 год, 84 за 2025-й и 119 с начала 2026 года по 6 октября. Из последних 119 инцидентов 81 произошел в июле или позднее. В подсчет включали случаи кражи или утечки персональных данных через веб-системы японских организаций, но исключали атаки вымогателей и эпизоды, которые связывали с другими группами. В 65 из 81 инцидента, раскрытого после июля, опубликованных сведений оказалось недостаточно, чтобы понять, каким путем злоумышленники проникли внутрь.
Похожие случаи Macnica обнаружила еще в 13 странах и регионах: всего 99 эпизодов, главным образом с июля по сентябрь 2026 года. На Южную Корею пришлось 30 случаев, на Францию 11, на Польшу 8. Сравнивать страны напрямую трудно: требования к раскрытию утечек и практика отчетности различаются. Macnica не знает, ограничена ли кампания Японией. В зоне риска оказались интернет-магазины, сервисы для участников программ лояльности, клиентская поддержка, деловые системы, мобильные приложения, BI-инструменты, внутренние API, каталоги библиотек и системы бронирования мест в туристических поездах. Административные и предназначенные для сотрудников интерфейсы иногда были доступны из интернета, хотя их владельцы этого не предполагали.
Один из самых крупных эпизодов связан с Park24 и сервисом каршеринга Times Car. 28 сентября 2026 года Park24 сообщил, что третья сторона получила данные примерно 6,6 млн учетных записей в веб-системе Times Car. На следующий день компания раскрыла дополнительную информацию: из примерно 1,6 млн учетных записей утекли также документы, включая изображения водительских удостоверений. На момент публикации причина оставалась под расследованием. Другой заметный случай затронул сеть ресторанов Yakiniku King, которой управляет Monogatari Corporation. По данным, опубликованным INTERNET Watch 5 октября 2026 года, из системы участников приложения Yakiniku King утекли 10 788 963 записи; точный способ атаки также еще выяснялся.
Первый сценарий: мобильное приложение как карта к API
JPCERT/CC описал три варианта злоупотребления API, стоящими за мобильными приложениями. В первом нападающие анализируют публично выпущенное приложение, находят адреса API и ключи, встроенные в программу или используемые ею, а затем отправляют запросы напрямую. Macnica зафиксировала случаи, когда ключи извлекали из мобильных приложений и обращались к API так, будто запросы исходили от обычного пользователя. Во втором случае атаковали внутренние API, недоступные через стандартные экраны приложения: меняли права пользователей, создавали несанкционированные учетные записи и сравнивали ответы сервера после добавления или удаления заголовков либо отправки поврежденного токена аутентификации. Так обнаруживались сведения об учетных записях через слепую NoSQL-инъекцию и открывались административные функции. В третьем варианте повторно применяли API-ключи, украденные после компрометации другой системы.
Проверке подвергались любые слабые места, способные раскрыть данные. API могли возвращать больше информации, чем требовалось, предоставлять чрезмерные права или разрешать анонимным пользователям пользоваться функциями для участников. Среди причин также назывались ошибки бизнес-логики, дефекты управления сессиями, слабые пароли административных экранов, известные уязвимости, отсутствие корректного контроля доступа и ненужная публикация систем управления. По оценке Macnica, злоумышленники могут последовательно проверять практически любой доступный из интернета веб-сервис, где хранятся персональные данные, а не выбирать организации по одному заранее известному признаку.
Второй сценарий: массовый поиск уязвимых систем
JPCERT/CC допускает, что единой уязвимости для всех пострадавших не существует. Нападающие могут сканировать каждую организацию отдельно, искать набор известных дефектов и использовать тот, который обнаружится на конкретном сервере. В ход идут также ошибки администрирования, конфигурационные и резервные файлы, ранее успешные приемы против других целей. В журналах стоит искать интенсивный API-трафик с одного адреса, резкий рост ответов HTTP 403, 404 и 503, запросы к несуществующим файлам и функциям API, а также необычно большой объем обращений, даже если сервер отвечает кодом HTTP 200. Отдельного внимания требуют административные функции, недоступные обычным пользователям, подозрительное выполнение команд, обращения к панели управления с необычных адресов, одновременный рост нагрузки на базу данных и сессии, ошибки в журналах базы и всплеск попыток входа. Macnica советует просмотреть как минимум журналы за предыдущий месяц.
Третий сценарий: уязвимость Metabase CVE-2026-72898
Metabase, открытый инструмент бизнес-аналитики, подключаемый к базам данных, стал отдельной целью. Уязвимость CVE-2026-72898 имеет тип SQL-инъекции и максимальную оценку CVSS 10.0. 6 августа 2026 года Metabase сообщил, что дефект уже эксплуатировался как zero-day против собственного облачного сервиса. Учетная запись для атаки не требовалась: уязвимость позволяла внедрить SQL в базу самого приложения Metabase и получить права администратора. После этого злоумышленник мог украсть учетные данные подключенных баз, читать их содержимое и экспортировать данные.
Агентство США по кибербезопасности и безопасности инфраструктуры (U.S. Cybersecurity and Infrastructure Security Agency, CISA) внесло CVE-2026-72898 в каталог Known Exploited Vulnerabilities 11 августа 2026 года. JPCERT/CC предупредил о проблеме 14 августа, а в новом уведомлении указал три IP-адреса, использовавшиеся с начала августа до начала сентября, и два User-Agent. Организации-цели по этим адресам названы не были. Атаки продолжались и после выхода исправления: AhaSlides сообщила, что третья сторона использовала уязвимость в ее развертывании Metabase и сохраняла доступ с 12 августа по 7 сентября 2026 года.
Исправление CVE-2026-72898 вошло в обновление Metabase от 6 августа. 11 августа проект выпустил еще одно критическое уведомление по проблемам, выявленным собственной командой, а затем повысил минимальные безопасные версии. Для открытых сборок список выглядит так:
После обновления системы, если endpoint сброса пароля был доступен из интернета, Metabase рекомендует отозвать все активные пользовательские сессии, проверить API-ключи и удалить неизвестные, изучить административные учетные записи на предмет неожиданных изменений, заменить учетные данные всех подключенных баз, проверить журналы хранилищ данных и историю активности и запросов Metabase. JPCERT/CC советует дополнительно ограничивать частоту запросов, устанавливая отдельные лимиты для входа, сброса пароля, отправки SMS и поиска. Каждый endpoint должен проверять права доступа и разрешенные HTTP-методы, API-токены следует выдавать по принципу минимальных полномочий, ограничивать по сроку действия и уметь быстро отзывать.
Для API мобильных приложений Macnica рекомендует не встраивать секретные ключи и учетные данные баз данных в поставляемые приложения и клиентский код браузера. Минификация и обфускация не превращают секрет в надежно защищенный: его все равно можно извлечь. Административные функции нужно включать в тесты на уязвимости, а не оставлять за пределами проверки. JPCERT/CC также предлагает ограничивать доступ по географии, если сервис предназначен только для одного региона, отключать ненужные административные функции в интернете и удалять данные после окончания срока хранения. Дополнительные рекомендации опубликованы в материалах OWASP, включая OWASP API Security Top 10.
Для проверки API-злоупотреблений JPCERT/CC приводит следующие адреса и User-Agent:
Пока не установлены ни личность нападающего или группы, ни единый источник всех атак, ни соответствие каждого метода конкретной публичной утечке. Неизвестно также, какой организации принадлежит каждый IP-адрес, является ли Япония единственной целью и применялся ли искусственный интеллект. Доказательств использования ИИ или обнаруженных с его помощью zero-day-уязвимостей в распространенном программном обеспечении нет. Автор анализа Macnica считает, что полностью исключить ИИ трудно: вручную проверить такое количество сайтов было бы нереалистично. При этом картина больше похожа на широкое зондирование и эксплуатацию базовых ошибок в правах доступа, конфигурации, аутентификации и своевременности установки исправлений.
7 октября 2026 года собственное предупреждение выпустила Комиссия Японии по защите персональной информации (Japan's Personal Information Protection Commission). Она обратилась к компаниям, обрабатывающим персональные данные, после случаев несанкционированного доступа к широко используемым сервисам и утечек больших массивов информации. В тот же день комиссия обновила руководство по утечкам из-за несанкционированного доступа и добавила пример злоупотребления API: атакующий входит в мобильное приложение или веб-сервис, меняет параметры запроса, после чего получает данные других пользователей. Компаниям предложено заново проверить, действительно ли им необходимо хранить весь имеющийся массив персональных данных. JPCERT/CC продолжит обновлять предупреждение по мере появления сведений о причинах и способах атак.
Изображение носит иллюстративный характер
Масштаб роста виден по данным японской компании Macnica. Ее Security Research Center опубликовал анализ 7 октября 2026 года на основе материалов реагирования на инциденты и изучения журналов; JPCERT/CC сослался на эту работу. Macnica насчитала в Японии 62 похожих случая за 2024 год, 84 за 2025-й и 119 с начала 2026 года по 6 октября. Из последних 119 инцидентов 81 произошел в июле или позднее. В подсчет включали случаи кражи или утечки персональных данных через веб-системы японских организаций, но исключали атаки вымогателей и эпизоды, которые связывали с другими группами. В 65 из 81 инцидента, раскрытого после июля, опубликованных сведений оказалось недостаточно, чтобы понять, каким путем злоумышленники проникли внутрь.
Похожие случаи Macnica обнаружила еще в 13 странах и регионах: всего 99 эпизодов, главным образом с июля по сентябрь 2026 года. На Южную Корею пришлось 30 случаев, на Францию 11, на Польшу 8. Сравнивать страны напрямую трудно: требования к раскрытию утечек и практика отчетности различаются. Macnica не знает, ограничена ли кампания Японией. В зоне риска оказались интернет-магазины, сервисы для участников программ лояльности, клиентская поддержка, деловые системы, мобильные приложения, BI-инструменты, внутренние API, каталоги библиотек и системы бронирования мест в туристических поездах. Административные и предназначенные для сотрудников интерфейсы иногда были доступны из интернета, хотя их владельцы этого не предполагали.
Один из самых крупных эпизодов связан с Park24 и сервисом каршеринга Times Car. 28 сентября 2026 года Park24 сообщил, что третья сторона получила данные примерно 6,6 млн учетных записей в веб-системе Times Car. На следующий день компания раскрыла дополнительную информацию: из примерно 1,6 млн учетных записей утекли также документы, включая изображения водительских удостоверений. На момент публикации причина оставалась под расследованием. Другой заметный случай затронул сеть ресторанов Yakiniku King, которой управляет Monogatari Corporation. По данным, опубликованным INTERNET Watch 5 октября 2026 года, из системы участников приложения Yakiniku King утекли 10 788 963 записи; точный способ атаки также еще выяснялся.
Первый сценарий: мобильное приложение как карта к API
JPCERT/CC описал три варианта злоупотребления API, стоящими за мобильными приложениями. В первом нападающие анализируют публично выпущенное приложение, находят адреса API и ключи, встроенные в программу или используемые ею, а затем отправляют запросы напрямую. Macnica зафиксировала случаи, когда ключи извлекали из мобильных приложений и обращались к API так, будто запросы исходили от обычного пользователя. Во втором случае атаковали внутренние API, недоступные через стандартные экраны приложения: меняли права пользователей, создавали несанкционированные учетные записи и сравнивали ответы сервера после добавления или удаления заголовков либо отправки поврежденного токена аутентификации. Так обнаруживались сведения об учетных записях через слепую NoSQL-инъекцию и открывались административные функции. В третьем варианте повторно применяли API-ключи, украденные после компрометации другой системы.
Проверке подвергались любые слабые места, способные раскрыть данные. API могли возвращать больше информации, чем требовалось, предоставлять чрезмерные права или разрешать анонимным пользователям пользоваться функциями для участников. Среди причин также назывались ошибки бизнес-логики, дефекты управления сессиями, слабые пароли административных экранов, известные уязвимости, отсутствие корректного контроля доступа и ненужная публикация систем управления. По оценке Macnica, злоумышленники могут последовательно проверять практически любой доступный из интернета веб-сервис, где хранятся персональные данные, а не выбирать организации по одному заранее известному признаку.
Второй сценарий: массовый поиск уязвимых систем
JPCERT/CC допускает, что единой уязвимости для всех пострадавших не существует. Нападающие могут сканировать каждую организацию отдельно, искать набор известных дефектов и использовать тот, который обнаружится на конкретном сервере. В ход идут также ошибки администрирования, конфигурационные и резервные файлы, ранее успешные приемы против других целей. В журналах стоит искать интенсивный API-трафик с одного адреса, резкий рост ответов HTTP 403, 404 и 503, запросы к несуществующим файлам и функциям API, а также необычно большой объем обращений, даже если сервер отвечает кодом HTTP 200. Отдельного внимания требуют административные функции, недоступные обычным пользователям, подозрительное выполнение команд, обращения к панели управления с необычных адресов, одновременный рост нагрузки на базу данных и сессии, ошибки в журналах базы и всплеск попыток входа. Macnica советует просмотреть как минимум журналы за предыдущий месяц.
Третий сценарий: уязвимость Metabase CVE-2026-72898
Metabase, открытый инструмент бизнес-аналитики, подключаемый к базам данных, стал отдельной целью. Уязвимость CVE-2026-72898 имеет тип SQL-инъекции и максимальную оценку CVSS 10.0. 6 августа 2026 года Metabase сообщил, что дефект уже эксплуатировался как zero-day против собственного облачного сервиса. Учетная запись для атаки не требовалась: уязвимость позволяла внедрить SQL в базу самого приложения Metabase и получить права администратора. После этого злоумышленник мог украсть учетные данные подключенных баз, читать их содержимое и экспортировать данные.
Агентство США по кибербезопасности и безопасности инфраструктуры (U.S. Cybersecurity and Infrastructure Security Agency, CISA) внесло CVE-2026-72898 в каталог Known Exploited Vulnerabilities 11 августа 2026 года. JPCERT/CC предупредил о проблеме 14 августа, а в новом уведомлении указал три IP-адреса, использовавшиеся с начала августа до начала сентября, и два User-Agent. Организации-цели по этим адресам названы не были. Атаки продолжались и после выхода исправления: AhaSlides сообщила, что третья сторона использовала уязвимость в ее развертывании Metabase и сохраняла доступ с 12 августа по 7 сентября 2026 года.
Исправление CVE-2026-72898 вошло в обновление Metabase от 6 августа. 11 августа проект выпустил еще одно критическое уведомление по проблемам, выявленным собственной командой, а затем повысил минимальные безопасные версии. Для открытых сборок список выглядит так:
- []ветка 63: исправление CVE-2026-72898 в 0.63.5, минимальная безопасная версия 0.63.13;
[]ветка 62: 0.62.9 и 0.62.16;
[]ветка 61: 0.61.11 и 0.61.18;
[]ветка 60: 0.60.17 и 0.60.24;
[]ветка 59: 0.59.21 и 0.59.28;
[]ветка 58: 0.58.24 и 0.58.31.
После обновления системы, если endpoint сброса пароля был доступен из интернета, Metabase рекомендует отозвать все активные пользовательские сессии, проверить API-ключи и удалить неизвестные, изучить административные учетные записи на предмет неожиданных изменений, заменить учетные данные всех подключенных баз, проверить журналы хранилищ данных и историю активности и запросов Metabase. JPCERT/CC советует дополнительно ограничивать частоту запросов, устанавливая отдельные лимиты для входа, сброса пароля, отправки SMS и поиска. Каждый endpoint должен проверять права доступа и разрешенные HTTP-методы, API-токены следует выдавать по принципу минимальных полномочий, ограничивать по сроку действия и уметь быстро отзывать.
Для API мобильных приложений Macnica рекомендует не встраивать секретные ключи и учетные данные баз данных в поставляемые приложения и клиентский код браузера. Минификация и обфускация не превращают секрет в надежно защищенный: его все равно можно извлечь. Административные функции нужно включать в тесты на уязвимости, а не оставлять за пределами проверки. JPCERT/CC также предлагает ограничивать доступ по географии, если сервис предназначен только для одного региона, отключать ненужные административные функции в интернете и удалять данные после окончания срока хранения. Дополнительные рекомендации опубликованы в материалах OWASP, включая OWASP API Security Top 10.
Для проверки API-злоупотреблений JPCERT/CC приводит следующие адреса и User-Agent:
- []3.112.252[.]14, 54.95.112[.]6, 69.10.51[.]162, 172.86.91[.]7, 210.149.87[.]120;
[]curl/7.88.1;
[]python-requests/2.34.2;
[]Mozilla/5.0 (Macintosh; Intel Mac OS X 10_15_7) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/126.0 Safari/537.36.
Пока не установлены ни личность нападающего или группы, ни единый источник всех атак, ни соответствие каждого метода конкретной публичной утечке. Неизвестно также, какой организации принадлежит каждый IP-адрес, является ли Япония единственной целью и применялся ли искусственный интеллект. Доказательств использования ИИ или обнаруженных с его помощью zero-day-уязвимостей в распространенном программном обеспечении нет. Автор анализа Macnica считает, что полностью исключить ИИ трудно: вручную проверить такое количество сайтов было бы нереалистично. При этом картина больше похожа на широкое зондирование и эксплуатацию базовых ошибок в правах доступа, конфигурации, аутентификации и своевременности установки исправлений.
7 октября 2026 года собственное предупреждение выпустила Комиссия Японии по защите персональной информации (Japan's Personal Information Protection Commission). Она обратилась к компаниям, обрабатывающим персональные данные, после случаев несанкционированного доступа к широко используемым сервисам и утечек больших массивов информации. В тот же день комиссия обновила руководство по утечкам из-за несанкционированного доступа и добавила пример злоупотребления API: атакующий входит в мобильное приложение или веб-сервис, меняет параметры запроса, после чего получает данные других пользователей. Компаниям предложено заново проверить, действительно ли им необходимо хранить весь имеющийся массив персональных данных. JPCERT/CC продолжит обновлять предупреждение по мере появления сведений о причинах и способах атак.
