Хакеры внедрили троян в axios — библиотеку кода, лежащую в основе большей части интернета. Ваша команда, скорее всего, затронута

Злоумышленники похитили долгосрочный токен доступа npm, принадлежавший ведущему сопровождающему axios — самой популярной библиотеки HTTP-клиентов для JavaScript, — и использовали его для публикации двух зараженных версий, которые устанавливают кроссплатформенный троян удаленного доступа. Вредоносные релизы ориентированы на macOS, Windows и Linux. Они находились в реестре npm примерно три часа до их удаления.

Axios загружают более 100 миллионов раз в неделю. Как сообщает Wiz, библиотека используется примерно в 80% облачных и кодовых сред, затрагивая всё: от фронтендов на React до конвейеров CI/CD и бессерверных функций. Компания Huntress зафиксировала первые заражения спустя 89 секунд после выхода вредоносного пакета и подтвердила по меньшей мере 135 скомпрометированных систем среди своих клиентов за время окна экспозиции.

Это уже третья крупная атака на цепочку поставок npm за последние семь месяцев. Каждая из них эксплуатировала учетные данные сопровождающих. На этот раз цель приняла все меры защиты, рекомендованные экспертным сообществом по безопасности.

Одна учетная запись, две ветки, 39 минут

Злоумышленник захватил учетную запись npm пользователя @jasonsaayman, ведущего мейнтейнера axios, изменил адрес электронной почты учетной записи на анонимный адрес ProtonMail и опубликовал зараженные пакеты через интерфейс командной строки npm. Это позволило полностью обойти конвейер CI/CD GitHub Actions проекта.

Злоумышленник ни разу не прикоснулся к исходному коду Axios. Вместо этого в обе ветки релиза была добавлена всего одна новая зависимость: plain-crypto-js@4.2.1. Ни одна часть кодовой базы ее не импортирует. Пакет существует исключительно для того, чтобы запустить постинсталляционный скрипт, который доставляет кроссплатформенный RAT на компьютер разработчика.

Подготовка была выверена с точностью. За восемь часов до релиза axios злоумышленник опубликовал чистую версию plain-crypto-js под другой учетной записью npm, чтобы наработать историю публикаций и обмануть оповещения сканеров новых пакетов. Затем последовала вредоносная версия 4.2.1. Обе релизные ветки были скомпрометированы в течение 39 минут. Было предварительно собрано три платформо-специфичных полезных нагрузки. После выполнения вредоносное ПО стирает само себя и подменяет файл package.json чистым, чтобы затруднить криминалистический анализ.

Компания StepSecurity, обнаружившая компрометацию наряду с Socket, назвала эту атаку одной из самых технологически изощренных атак на цепочку поставок из всех, что когда-либо фиксировались в отношении пакетов из топ-10 экосистемы npm.

Защита, существовавшая только на бумаге

Axios все сделали правильно. Легитимные релизы версии 1.x выпускались через GitHub Actions с использованием механизма OIDC Trusted Publisher от npm, который криптографически связывает каждую публикацию с проверенным рабочим процессом CI/CD. В проекте использовались аттестации происхождения SLSA. По всем современным меркам стек безопасности выглядел надежным.

Ничто из этого не помогло. Компания Huntress изучила рабочий процесс публикации и обнаружила брешь. В проекте по-прежнему передавался NPM_TOKEN в качестве переменной окружения прямо рядом с учетными данными OIDC. Когда присутствуют оба фактора, npm по умолчанию отдает приоритет токену. Долгосрочный классический токен оставался реальным методом аутентификации для любой публикации независимо от того, как был настроен OIDC. Злоумышленнику даже не пришлось взламывать OIDC. Он просто обошел его. Устаревший токен оставался там в качестве параллельного пути авторизации, и собственная иерархия npm молчаливо отдавала ему предпочтение.

«По моему опыту работы в AWS, старые механизмы авторизации сохраняются очень часто», — отметила в эксклюзивном интервью VentureBeat Мерритт Бэр (Merritt Baer), директор по информационной безопасности в Enkrypt AI и бывший заместитель директора по информационной безопасности в AWS. — «Современные средства защиты внедряются, но если устаревшие токены или ключи не выводятся из эксплуатации, система тихо отдает предпочтение им. Точно так же, как мы видели в случае с SolarWinds, где устаревшие скрипты обходили более новые системы мониторинга».

Мейнтейнер опубликовал сообщение на GitHub после обнаружения взлома: «Я пытаюсь добиться от поддержки понимания того, как это вообще произошло. У меня настроена двухфакторная аутентификация (2FA / MFA) практически для всего, с чем я взаимодействую».

Компания Endor Labs задокументировала криминалистическую разницу. Легитимный axios@1.14.0 демонстрировал данные о происхождении OIDC, запись доверенного издателя и gitHead, ссылающийся на конкретный коммит. У вредоносного axios@1.14.1 ничего этого не было. Любой инструмент, проверяющий происхождение, мгновенно выявил бы этот пробел. Но верификация происхождения является опциональной. Ни один шлюз реестра не отклонил пакет.

Три атаки, семь месяцев, та же первопричина

Три атаки на цепочку поставок npm за семь месяцев. Каждая из них начиналась со скомпрометированных учетных данных сопровождающего.

Червь Shai-Hulud атаковал систему в сентябре 2025 года. Единственная взломанная путем фишинга учетная запись мейнтейнера предоставила злоумышленникам плацдарм, который самовоспроизвелся в более чем 500 пакетах, собирая по мере распространения токен npm, облачные учетные данные и секреты GitHub. Агентство CISA выпустило предупреждение. В ответ GitHub полностью переработал модель аутентификации npm’.

Затем в январе 2026 года исследование PackageGate от компании Koi Security выявило шесть уязвимостей нулевого дня в npm, pnpm, vlt и Bun, которые пробили те самые защитные механизмы, что были приняты экосистемой после инцидента с Shai-Hulud. Целостность файл-локов (lockfile) и блокировка скриптов в определенных условиях дали сбой. Три из четырех менеджеров пакетов выпустили патчи в течение нескольких недель. npm закрыла отчет.

Теперь пострадал axios. Украденный долгосрочный токен опубликовал RAT через обе релизные ветки вопреки наличию OIDC, SLSA и всех мер укрепления безопасности, принятых после Shai-Hulud.

После инцидента с Shai-Hulud компания npm внедрила реальные реформы. Создание новых классических токенов было объявлено устаревшим, хотя уже существовавшие продолжили работать до наступления жесткого дедлайна отзыва. Двухфакторная аутентификация FIDO стала обязательной, срок действия гранулярных токенов доступа для публикации был ограничен семью днями, а доверенная публикация через OIDC предоставила проектам криптографическую альтернативу сохраненным учетным данным. В совокупности эти изменения укрепили все элементы, находящиеся ниже по цепочке от учетной записи мейнтейнера. Единственное, что они не изменили — это саму учетную запись. Учетные данные оставались единой точкой отказа.

«Компрометация учетных данных — это повторяющаяся тема во всех взломах npm, — говорит Бэр. — Это проблема не просто слабых паролей. Она носит структурный характер. Без эфемерных учетных данных, принудительного использования MFA или изолированных сред сборки и подписания доступ мейнтейнеров остается слабым звеном».

Что внедрило npm против того, что эта атака обошла стороной

Что делать вашему предприятию прямо сейчас

Руководители SOC в организациях, использующих Node.js, должны рассматривать этот инцидент как активную угрозу до тех пор, пока не подтвердят чистоту своих систем. Трехчасовое окно экспозиции пришлось на часы пик разработки в часовых поясах Азиатско-Тихоокеанского региона, и любой конвейер CI/CD, выполнивший команду npm install ночью, мог автоматически подтянуть скомпрометированную версию.

«Первоочередная задача — оценка масштаба ущерба: какие сборки и зависимые потребители загрузили скомпрометированный пакет? — говорит Бэр. — Затем локализация, устранение уязвимостей и, наконец, прозрачное информирование руководства. Что произошло, что подверглось угрозе и какие меры предотвратят повторение. Уроки Log4j и event-stream показывают, что скорость и ясность имеют такое же значение, как и сам исправительный патч».

• Проверьте степень подверженности угрозе. Ищите в lock-файлах и логах CI упоминания axios@1.14.1, axios@0.30.4 или plain-crypto-js. Зафиксируйте версии на axios@1.14.0 или axios@0.30.3..

• Считайте системы скомпрометированными в случае обнаружения. Пересоберите пострадавшие машины из гарантированно чистых образов. Перевыпустите все доступные учетные данные: токены npm, ключи AWS, ключи SSH, облачные учетные данные, секреты CI/CD, значения .env.

• Заблокируйте командный сервер (C2). Добавьте sfrclak.com и 142.11.206.73 в черные списки DNS и правила межсетевого экрана.

• Проверьте наличие артефактов RAT. /Library/Caches/com.apple.act.mond в macOS. %PROGRAMDATA%wt.exe в Windows. /tmp/ld.py on Linux. При обнаружении выполните полную пересборку.

• Усильте защиту в дальнейшем. Применяйте npm ci --ignore-scripts в CI/CD в обязательном порядке. Требуйте установку исключительно на основе lock-файлов. Отклоняйте пакеты без данных о происхождении от проектов, у которых эти данные ранее присутствовали. Проведите аудит на предмет сосуществования устаревших токенов с OIDC в собственных рабочих процессах публикации.

Пробел в безопасности учетных данных, который так никто и не закрыл

Три атаки за семь месяцев. Каждая отличается по исполнению, но имеет идентичную первопричину. Модель безопасности npm по-прежнему рассматривает индивидуальные учетные записи мейнтейнеров как главный якорь доверия. Эти учетные записи остаются уязвимыми для перехвата доступов независимо от того, сколько уровней защиты добавляется ниже по цепочке.

«ИИ выявляет рискованные пакеты, проводит аудит устаревшей авторизации и ускоряет реакцию SOC, — резюмирует Бэр. — Но учетными данными мейнтейнеров по-прежнему управляют люди. Мы снижаем риски, но не устраняем их полностью».

Обязательная аттестация происхождения, при которой ручная публикация через CLI полностью отключена, предотвратила бы эту атаку еще до попадания пакета в реестр. То же самое касалось бы и обязательного многостороннего подписания (multi-party signing), при котором ни один мейнтейнер не может выпустить релиз в одиночку. Ни то, ни другое сегодня не является обязательным. Компания npm дала понять, что отключение токенов по умолчанию при включенной доверенной публикации входит в ее планы. Пока это не реализовано, каждый проект, использующий OIDC наряду с устаревшим токеном, имеет ту же слепую зону, что и axios.

Сопровождающий axios сделал то, о чем просила comunidade. Но устаревший токен, о чьей активности никто не подозревал, свел на нет все эти усилия.