Исследователь безопасности Wahid Fayad заявил, что обнаружил в Azure Portal сценарий подмены зависимости ( dependency confusion) через публичный npm-реестр. Он сообщил о находке в Microsoft Security Response Center, но MSRC закрыл кейс: команда посчитала, что доказательства удаленного выполнения кода не указывают на эксплуатируемую уязвимость в продуктовой инфраструктуре.
История началась в январе 2026 года во время анализа JavaScript-ресурсов, которые загружались с portal.azure.com. Исследователь нашел в клиентском коде обращение к внутреннему npm-модулю @FxInternal/NetDiagnostics. При проверке выяснилось, что соответствующего пространства имен и пакета в публичном npm-реестре нет. Это значит, что если внутренний пакет не защищен на публичной стороне, злоумышленник может занять такое имя и попытаться заставить сборочную систему или окружение разработчика загрузить уже публичную версию.
Проблема возникает на границе между внутренними и внешними источниками пакетов. Компания использует приватный модуль, но его имя доступно в публичном реестре. Если пакетный менеджер, прокси или сборочная среда выбирает публичный пакет с тем же именем, атакующий получает шанс выполнить свой код там, где разработчики ожидали доверенную внутреннюю зависимость.
Для проверки гипотезы Fayad зарегистрировал пространство имен @fxinternal и опубликовал пакет @fxinternal/netdiagnostics. Дальше он выпустил версию с безвредным out-of-band callback — сетевым запросом, который должен был показать, запускается ли пакет где-то в инфраструктуре Microsoft. Callback действительно сработал. Исследователь утверждает, что запрос пришёл из AS8075, автономной системы Microsoft, а переданные данные указывали на путь установки в node_modules, внутреннее имя хоста и имя пользователя.
С точки зрения исследователя это было подтверждением удаленного выполнения кода: публичный npm-пакет установился и запустился в среде, связанной с Microsoft. В отчете он также указывал на признаки бэкенд-пайплайна и автоматизированных проверок, которые обращались к Azure-компонентам.
MSRC принял отчёт 28 января 2026 года, на следующий день получил дополнительные данные, а затем пришёл к другому выводу. Microsoft сообщила исследователю, что зависимость FxInternal/NetDiagnostics разрешается внутри инфраструктуры portal.azure.com, поэтому сценарий сложно считать эксплуатируемой уязвимостью. Позже MSRC указал, что callback, по оценке команды, поступил не из продакшн-сборки и не из рантайм-пайплайна, а из автоматизированного инструмента безопасности. Кейс закрыли 24 марта. Апелляция исследователя результата не изменила.
Для исследователя сетевой запрос из инфраструктуры Microsoft после публикации публичного пакета — достаточный сигнал риска. Для MSRC важнее контекст выполнения: где именно пакет запускался, имел ли доступ к чувствительным данным, мог ли попасть в продуктовую сборку и существовал ли путь эксплуатации для внешнего атакующего.
Ситуацию усложняет реакция внешней экосистемы. Пакет попал в GitHub Advisory Database и получил критический рейтинг 9.3 по CVSS. Такая оценка не означает автоматического признания уязвимости Microsoft, но показывает, что сторонние системы безопасности восприняли пакет как угрозу цепочке поставки. Для разработчиков это могло выглядеть как вредоносный пакет, имитирующий внутреннюю зависимость крупного поставщика.
А в конце мая Microsoft сама выпустила отдельный отчет о реальной атаке через dependency confusion: злоумышленник опубликовал 33 вредоносных npm-пакета под девятью организационными scope, имитируя внутренние корпоративные пространства имён. Пакеты использовали postinstall-хуки, обфускацию, загрузку полезной нагрузки с C2-сервера и сбор данных о developer- и build-окружениях. То есть сама техника dependency confusion активно используется в атаках на цепочки поставки.
В кампании, описанной Microsoft, вредоносные пакеты маскировались под внутренние сервисы, инструменты мониторинга, платежные SDK, UI-компоненты, модули авторизации и другие корпоративные зависимости. Часть пакетов имела завышенные номера версий, чтобы выиграть разрешение зависимости у внутреннего пакета. Такой трюк давно известен: если пакетный менеджер выбирает «самую новую» версию без привязки к приватному реестру, публичный пакет атакующего может получить приоритет.
Самый опасный элемент таких атак — автоматическое выполнение кода во время установки. В npm это часто происходит через lifecycle scripts, например postinstall. Разработчик или CI/CD-пайплайн запускает установку зависимостей, пакет выполняет скрипт, после чего может собрать сведения о системе, переменных окружения, ключах, токенах, путях проекта и окружении сборки. Для атакующего это идеальный разведывательный этап перед более серьезной операцией.
Есть новость? Станьте автором.
Мы сотрудничаем с независимыми исследователями и специалистами по кибербезопасности. Отправьте нам новость или предложите статью на рассмотрение редакции.
