Японский телеком-гигант KDDI сообщил, что утечка данных KDDI затронула 12 233 087 email-адресов и 7 616 173 пароля. Для рынка это не просто очередной инцидент у крупного оператора, а показательный сбой в цепочке подрядчиков: одна уязвимость во внешнем ПО ударила сразу по нескольким интернет-провайдерам и миллионам учетных записей.
Речь идет о взломе почтовой платформы, которую использовали пять японских ISP: STNet, JCOM, Chubu Telecommunications C, NIFTY Corporation и BIGLOBE. По данным BleepingComputer, злоумышленники получили доступ к системе 16 мая 2026 года, использовав zero-day в стороннем программном обеспечении. Сам KDDI обнаружил инцидент позже, 17 июня, после чего заявил, что перекрыл доступ атакующим и начал защитные мероприятия.
Дальше начинаются цифры, из-за которых новость и вышла за пределы локального японского рынка. Компания сначала говорила, что потенциально могли быть затронуты до 14,22 млн текущих и бывших клиентов, а также неактивные аккаунты. Затем в обновлении от 6 июля уточнила фактический масштаб: доступны злоумышленникам оказались 12,2 млн адресов электронной почты и 7,6 млн паролей. Это важная разница. В одном случае речь о максимально широком контуре проверки, в другом — о подтвержденных данных, по которым можно оценивать реальный ущерб и сценарии последующих атак.
Отдельно KDDI признала неприятную деталь: часть паролей хранилась в виде хэшей и/или в зашифрованном виде, но компания не раскрыла, сколько именно записей были защищены таким способом. Еще важнее, она не сообщила, какая доля паролей могла храниться в открытом виде и какой именно механизм шифрования или хэширования использовался. Для безопасников это не академический нюанс, а центральный вопрос. Если пароли были надежно захэшированы с современными параметрами, риск массового захвата учеток заметно ниже. Если нет, утечка быстро превращается из PR-кризиса в практический набор логинов для credential stuffing, фишинга и компрометации связанных сервисов.
Сам сценарий атаки тоже выглядит знакомо до боли. Не был взломан отдельно взятый клиентский аккаунт, не случилась ошибка одного администратора, не всплыл публичный бакет с бэкапом. Атакующие зашли через zero-day в стороннем ПО, то есть через компонент, который обычно живет где-то в зоне «поддерживается вендором, значит под контролем». KDDI прямо указала, что по состоянию на 17 июня уязвимость еще не была известна поставщику софта. Вендор уже сообщил о проблеме регуляторам и работает над ее раскрытием. Для ИТ-команд это хороший повод еще раз вспомнить неприятную истину: наличие SLA с подрядчиком не означает, что ваш риск-профиль передан на аутсорс. Он просто становится распределенным и хуже наблюдаемым.
После обнаружения инцидента KDDI начала принудительную смену паролей для затронутых аккаунтов. Компания уточнила, что многие пользователи, которые активно пользуются почтой, уже сменили пароли самостоятельно. Для тех, кто заходит в ящик редко, ISP-партнерам поручили завершить обязательную смену паролей в течение одного-двух дней. Параллельно KDDI внедрила EDR, а 23 июня, по ее словам, форензика подтвердила, что использованная уязвимость закрыта и других проблем в системе не найдено. Также оператор уведомил японскую комиссию по защите персональной информации и Министерство внутренних дел и коммуникаций.
С точки зрения бизнеса здесь важен не только объем базы, но и структура пострадавших данных. Email плюс пароль — это уже не просто «контактные данные ушли наружу». Это материал для каскадных атак, особенно если пользователи переиспользуют пароли между почтой, маркетплейсами, банковскими кабинетами, корпоративными порталами и SaaS-сервисами. Для российских и вообще русскоязычных ИТ-команд история выглядит очень прикладной. Во-первых, старые или неактивные аккаунты снова показывают себя как токсичный актив: они редко мониторятся, но хранят те же чувствительные данные. Во-вторых, интеграционная платформа или внешний сервис-провайдер может стать единым узким местом сразу для нескольких брендов. В-третьих, в кризисе быстро выясняется, насколько у компании реально готовы процедуры forced reset, оповещение клиентов, сбор доказательств и координация с регуляторами.
Для разработчиков и архитекторов в этой истории мало нового на уровне лозунгов, но много неприятной конкретики на уровне исполнения. Если сервис аутентификации или почтовая платформа внешние, нужно заранее понимать, как хранятся секреты, как быстро можно принудительно сбросить пароли, где лежат журналы событий, кто отвечает за форензику и какие индикаторы компрометации вообще доступны заказчику. Если ответы на эти вопросы начинаются с фразы «надо уточнить у вендора», то в день инцидента уже поздно. Утечка данных KDDI еще раз показывает: безопасность подрядчика нужно проверять не по презентации для тендера, а по способности пережить zero-day без многонедельной паузы между компрометацией и обнаружением.
Для рынка связи это еще и неприятный сигнал о концентрации риска. Один общий почтовый контур обслуживал сразу несколько операторов, а значит, атака на платформу автоматически масштабировалась на их клиентские базы. Именно поэтому утечка данных KDDI выглядит не локальным японским кейсом, а модельной историей для любого крупного бизнеса с экосистемой партнеров. Следующий большой вопрос здесь даже не в том, сколько еще подобных zero-day сидят в стороннем ПО, а в том, сколько компаний действительно умеют быстро доказать, какие именно данные уже ушли и какие учетные записи еще можно спасти, пока злоумышленники не монетизировали доступ.