Дата публикации
news

Компрометация axios в npm: вредоносные версии поставили под удар миллионы JS‑проектов

Что произошло

30 марта 2026 года StepSecurity обнаружила две вредоносные версии самой популярной JavaScript‑библиотеки для HTTP‑запросов — axios. Речь о релизах axios@1.14.1 и axios@0.30.4, опубликованных в npm.

Обе версии вышли не из нормального GitHub‑pipeline проекта, а через ручную публикацию в npm CLI. Для этого атакующий захватил учётную запись основного мейнтейнера axios в npm — jasonsaayman. В профиле сменили почту на анонимный адрес ifstap@proton.me и оттуда опубликовали заражённые сборки сразу в две ветки: современную 1.x и легаси‑линию 0.x. Разница между релизами — 39 минут.

Вредонос не в коде axios. В package.json добавили поддельную зависимость plain-crypto-js@4.2.1, которая нигде не импортируется. Её задача — выполнить postinstall‑скрипт node setup.js. Этот скрипт разворачивает кроссплатформенный RAT (Remote Access Trojan), который связывается с командным сервером, тянет второй этап атаки для macOS, Windows и Linux, запускает его и затем пытается скрыть следы. После установки вредонос самоуничтожается, а свой package.json подменяет «чистым» вариантом.

Перед этим злоумышленник аккуратно подготовил почву:

  • 2026‑03‑30 05:57 (UTC) — публикует plain-crypto-js@4.2.0 от имени nrwise@proton.me. Пакет содержит копию легитимного crypto‑js без postinstall. Нужен только для создания истории публикаций.
  • 2026‑03‑30 23:59 — выходит plain-crypto-js@4.2.1 с добавленным postinstall: "node setup.js" и обфусцированным дроппером.
  • 2026‑03‑31 00:21 — релиз axios@1.14.1 с зависимостью plain-crypto-js@4.2.1.
  • 2026‑03‑31 01:00 — релиз axios@0.30.4 с той же зависимостью.

StepSecurity выявила атаку с помощью AI Package Analyst и Harden-Runner, провела статический и рантайм‑анализ и уведомила мейнтейнеров. Компания называет атаку одной из самых технически сложных атак на supply chain против топ‑10 пакета в npm. Если вы устанавливали axios@1.14.1 или axios@0.30.4, нужно исходить из того, что система скомпрометирована.

Контекст

axios — де‑факто стандарт HTTP‑клиента в JavaScript‑мире. Его используют React‑фронтенды, Node.js‑бэкенды, CLI‑утилиты, CI/CD‑скрипты. У библиотеки больше 300 миллионов загрузок в неделю. Один неудачный минорный релиз способен зацепить огромное число проектов, от внутренних тулов до пользовательских сервисов.

Тут сошлись сразу несколько неприятных факторов.

Во‑первых, атака идёт через учётку мейнтейнера, а не через баг в коде. Для экосистемы это худший сценарий: привычные проверки источника пакета не помогают, подписи и история версий выглядят «правдоподобно».

Во‑вторых, злоумышленник заранее подготовил подставной пакет. Сначала вышла безобидная версия plain-crypto-js@4.2.0 с реальным кодом crypto‑js и без скриптов. Это убирает красный флаг «нулевая история публикаций», которым часто пользуются автоматические сканеры.

В‑третьих, вредонос ведёт себя максимально тихо. Зависимость нигде не импортируется, содержит только postinstall. RAT‑дроппер после выполнения удаляет свои следы и подменяет package.json на «чистый». Разработчик, который смотрит node_modules руками, почти наверняка ничего не увидит.

И наконец, цель — три операционные системы: macOS, Windows и Linux. Скрипт setup.js выбирает нужный путь: AppleScript для macOS, связку VBScript + PowerShell для Windows или Python cценарий для Linux. Всё это делает атаку не массовым баловством, а хорошо спланированной операцией с реальным командным центром.

Что это значит для вас

Если вы разрабатываете на JavaScript или поддерживаете инфраструктуру на Node.js, это прямой сигнал усилить защиту цепочки поставок.

  1. Проверьте версии axios.

    • Если где‑то в проекте, монорепе или приватном реестре фигурируют axios@1.14.1 или axios@0.30.4, относитесь к этим окружениям как к потенциально взломанным.
  2. Оцените, где мог выполниться postinstall.

    • CI/CD‑агенты, dev‑машины, staging и прод, где запускался npm install или npm update в окно атаки, — кандидаты на разбор.
  3. Ищите артефакты RAT.

    • Сеть: подозрительные исходящие соединения к неизвестным доменам C2 в момент установки зависимостей.
    • Файловая система: временные скрипты AppleScript/VBScript/Python, которые могли остаться на диске.
    • Логи процессов: неизвестные дочерние процессы npm/node во время установки.
  4. Немедленно обновите axios на безопасную версию.

    • Перейдите на стабильный релиз, опубликованный уже после инцидента.
    • Зафиксируйте версии зависимостей в lock‑файлах и включите аудит npm‑пакетов в CI.
  5. Ужесточите доступ к экосистемным аккаунтам.

    • Для npm‑учёток мейнтейнеров и владельцев внутренних пакетов включите 2FA.
    • Пересмотрите, кому и зачем нужны права публикации.
  6. Добавьте слой защиты на этапе сборки.

    • Инструменты класса StepSecurity Harden-Runner и AI‑аналитика пакетов дают шанс поймать такие атаки до деплоя.

Если вы продуктовый разработчик, DevOps или отвечаете за безопасность, относитесь к этому кейсу как к репетиции. Атака показала, что одного захваченного аккаунта в npm хватает, чтобы подставить под удар миллионы проектов. Теперь задача — сделать так, чтобы следующий захват не превратился в полный доступ к вашей инфраструктуре.


Читайте также

Компрометация axios в npm: вредоносные версии поставили под удар миллионы JS‑проектов — VogueTech | VogueTech