Очередной разбор атаки: под ударом axios
Axios — это один из самых популярных HTTP-клиентов в JavaScript-экосистеме. Его используют и во frontend, и в backend, и в разных скриптах автоматизации, и в CI/CD.
Но сейчас я хочу рассказать не о функциональности axios, а то, что произошла supply chain-атака.
━━━━━━━━━━ Что произошло ━━━━━━━━━━
30 марта стало известно, что в npm были опубликованы скомпрометированные версии: • axios@1.14.1 • axios@0.30.4
Самое неприятное в этой истории — атакующие не подменили какой-то левый пакет-клон. Под удар попали именно официальные релизы настоящего axios.
По имеющимся данным, злоумышленник получил доступ к npm-аккаунту одного из мейнтейнеров и уже от его имени опубликовал вредоносные версии. То есть для пользователя это выглядело как обычное обновление доверенной зависимости.
━━━━━━━━━━ Как состоялась атака ━━━━━━━━━━
В заражённые версии axios была добавлена зависимость plain-crypto-js@4.2.1.
И здесь важный момент: эта библиотека не нужна axios по прямому назначению. Она была добавлена как carrier для postinstall-скрипта.
Дальше схема выглядела так: ➣ разработчик / CI / Docker build ставит axios ➣ npm автоматически тянет plain-crypto-js ➣ срабатывает postinstall ➣ на хост подтягивается вторая стадия вредоносной нагрузки
Под ударом были: • macOS • Windows • Linux
То есть речь уже не про “сломанный пакет”, а про полноценную доставку RAT через доверенный канал поставки.
━━━━━━━━━━ На что были нацелены атакующие ━━━━━━━━━━
Если кратко — на доступ внутрь среды, где устанавливался пакет.
А это уже значит потенциальный интерес к: • env vars • токенам CI/CD • npm / GitHub / cloud credentials • SSH-ключам • другим секретам, доступным процессу установки
Особенно “неприятен” сценарий, когда заражённая версия ставилась не на локалке, а внутри pipeline или при сборке образов.
━━━━━━━━━━ Кто мог пострадать ━━━━━━━━━━
Проверяться стоит тем, кто: • ставил axios@1.14.1 или axios@0.30.4 вручную • обновлял зависимости в конце марта • собирал Docker-образы с npm install • использовал axios транзитивно через другие пакеты • гонял сборки/тесты в CI, где axios мог приехать автоматически
Отдельно важно: если в системе вообще появился node_modules/plain-crypto-js — это уже очень плохой признак, потому что в легитимных релизах axios такой зависимости быть не должно.
Для самопроверки можно использовать community scanner: ➥ https://github.com/axios/axios/issues/10611
Из IOC также стоит смотреть: • plain-crypto-js • sfrclak.com • 142.11.206.73 • /tmp/ld.py • /Library/Caches/com.apple.act.mond • %PROGRAMDATA%\wt.exe
#CyberSecurity #AppSec #DevSecOps #npm #JavaScript #axios #CICD
· 16.04
Фёдор, отличный разбор. Axios используем в каждом проекте — эта атака показала, насколько хрупка цепочка доверия в npm. Что мы внедрили после этого кейса: 1) lockfile-lint в CI — проверяет, что все зависимости идут из ожидаемого registry 2) npm audit в pre-commit hook — ловит уязвимости до коммита 3) Pinned versions + Renovate bot — никаких ^1.x.x, только exact versions с автоматическим review. AI-агент (Claude Code) помогает с аудитом: «проверь все зависимости на postinstall скрипты» — за минуту сканирует весь node_modules. Supply chain security — это не паранойя, это гигиена в 2026.
ответить
коммент удалён
· 16.04
Интересный подход, мне лично ближе реализация с OSA Proxy.
Когда прокси стоит перед внутренним хранилищем компании, через неё можно централизованно контролировать не только доверенные библиотеки, но и другие внутренние артефакты. И за счёт этого удобнее управлять сразу всеми командами разработки, проводить инвентаризацию и быстро внедрять единые политики ИБ.
ответить
ответ удалён