Toshiba и Muji предупредили пользователей о подозрительных окнах авторизации, которые всплывали прямо на их сайтах из-за старого подключения polyfill.io. История выглядит как мелкий сбой интерфейса, но для разработчиков и владельцев цифровых сервисов это более неприятный сигнал: забытый внешний JavaScript может вернуться спустя два года и снова поставить под удар логины, доверие пользователей и репутацию команды.
О проблеме сообщает BleepingComputer. По данным издания, японская Toshiba опубликовала короткое предупреждение для посетителей: если на сайте появляется экран входа, похожий на системный запрос логина и пароля, вводить данные не нужно, следует нажать Cancel. Компания отдельно уточнила, что работает над устранением этого экрана. Похожее сообщение выпустила и Muji. Ритейлер заявил, что признаков несанкционированного доступа или утечки информации на момент публикации не обнаружено, но пользователям, которые уже вводили учетные данные в таком окне, лучше сменить пароль.
Суть инцидента в том, что речь не идет о классическом взломе самих сайтов Toshiba или Muji. Источником проблемы оказался внешний сервис polyfill.io, который исторически использовался как CDN для JavaScript-полифилов, то есть для совместимости современных сайтов со старыми браузерами. В 2024 году домен polyfill.io уже оказался в центре крупного инцидента: после смены владельца в выдаваемые скрипты добавили вредоносный код, и тогда пострадали более 100 тысяч сайтов, использовавших этот сервис. После той истории создатель открытого проекта Эндрю Беттс публично рекомендовал владельцам сайтов отказаться от polyfill.io, а затем перезапустил сервис на других доменах: сначала polyfill.com, позже polyfill.top.
Казалось бы, история закрыта: опасный домен отключили, редиректы прекратились, рынок сделал выводы. Но, как это часто бывает с фронтендом и legacy-зависимостями, выводы сделали не все и не везде. Некоторые сайты за прошедшие два года так и не вычистили все следы старого подключения polyfill.io. Исследователь безопасности Паскуале Пиллиттери сообщил, что в конце мая 2026 года домен снова начал отвечать, но уже не вредоносным JavaScript, а HTTP 401. Для браузера это сигнал показать встроенный запрос имени пользователя и пароля. В итоге пользователь открывает страницу бренда, а вместо ожидаемого интерфейса видит чужеродное окно авторизации, которое легко принять за штатную часть сайта.
Именно поэтому инцидент выглядит коварнее, чем обычная поломка внешнего скрипта. Никакого сложного фишингового лендинга, никакой яркой красной сирены. Браузер сам рисует стандартное окно входа, а пользователь видит знакомый домен в адресной строке и может решить, что сайт просто попросил повторно залогиниться. На этом месте ломается не только техника, но и пользовательская привычка: если бренд крупный, многие нажимают дальше почти автоматически. Toshiba и Muji поэтому и рекомендовали тем, кто уже вводил данные, сменить пароль. На момент публикации подтверждений кражи учетных данных не было, но в таких историях лучше исходить не из оптимизма, а из модели «если окно возникло внезапно, оно уже подозрительно».
По сообщениям японских СМИ, проблемой могли быть затронуты и другие компании, включая Zojirushi, FiNC Technologies, Ishiyaku Publishers и онлайн-издательский бренд Hobonichi. Пиллиттери также утверждает, что 1 июня аналогичный логин-промпт появлялся на сайтах и телевизорах Samsung Smart TV. Это важная деталь: история давно вышла за рамки одной-двух страниц и показывает, насколько липкими бывают цепочки поставок во фронтенде. Зависимость могла быть добавлена много лет назад ради поддержки старых браузеров, затем про нее забыли, проект сменил владельца, домен начал жить собственной жизнью, а следы кода остались в шаблонах, виджетах, лендингах и редко посещаемых страницах.
Для русскоязычной IT-аудитории это кейс не столько про Японию, сколько про базовую гигиену зависимостей. У многих компаний фронтенд давно собирается через современные пайплайны, но рядом часто существуют маркетинговые микросайты, архивные разделы, старые промостраницы, SPA-проекты прошлых подрядчиков и CMS-шаблоны, где до сих пор лежат скрипты, о которых никто не вспоминает до первого инцидента. Если в 2024 году рынок обсуждал supply chain-атаку на уровне «проверьте, не подключен ли у вас polyfill.io», то кейс 2026 года добавляет менее удобный вывод: одной разовой проверки мало. Удаление зависимости должно быть подтверждено по всему периметру, а не только в основном репозитории.
У этой истории есть и более неприятный организационный смысл. Внешний сервис даже не обязан раздавать откровенно вредоносный код, чтобы создать проблему безопасности. Достаточно начать отвечать нестандартным образом, как это произошло с HTTP 401, и браузер сам достроит сценарий социальной инженерии. Для security-команд это напоминание, что инвентаризация third-party script'ов, контроль внешних доменов, мониторинг ответов CDN и регулярная зачистка legacy-страниц давно перестали быть скучной бюрократией. Это уже часть защиты учетных данных и бренда. Особенно в компаниях, где один забытый тег в шаблоне может пережить три редизайна, пять релизов и половину команды.
Инцидент с polyfill.io неприятен именно своей банальностью: никакой экзотики, просто старый внешний ресурс, который никто не довел до конца. И если в 2024 году это выглядело как громкая supply chain-атака, то в 2026-м история стала почти учебником о том, что риск не исчезает вместе с новостной волной. Он тихо сидит в чужом скрипте до тех пор, пока браузер не решит вежливо попросить у вашего пользователя пароль.