Зловмисники викрали довготривалий токен доступу npm, що належав провідному розробнику axios – найпопулярнішої бібліотеки HTTP-клієнта в JavaScript. Скориставшись цим, вони опублікували дві заражені версії, які встановлюють міжплатформний троян віддаленого доступу. Шкідливі версії націлені на macOS, Windows та Linux. Вони перебували в реєстрі npm приблизно три години до їх видалення.
Axios отримує понад 100 мільйонів завантажень на тиждень. За даними Wiz, ця бібліотека використовується приблизно у 80% хмарних середовищ та середовищ розробки коду, охоплюючи все – від фронтенд-систем на React до пайплайнів CI/CD та serverless-функцій. Huntress виявив перші інфікування через 89 секунд після виходу шкідливого пакету і підтвердив щонайменше 135 скомпрометованих систем серед своїх клієнтів у період вразливості.
Це вже третій масштабний компроміс ланцюжка постачання npm за останні сім місяців. Кожен із них експлуатував облікові дані розробників. Цього разу ціль впровадила всі рекомендовані спільнотою безпеки заходи захисту.
Один обліковий запис, дві гілки, 39 хвилин
Зловмисник отримав контроль над обліковим записом npm користувача @jasonsaayman, провідного розробника axios. Він змінив електронну адресу облікового запису на анонімну адресу ProtonMail і опублікував заражені пакети через командний рядок npm. Це повністю обійшло пайплайн CI/CD проекту GitHub Actions.
Атакувальник жодного разу не торкався вихідного коду Axios. Натомість обидві гілки випуску отримали одну нову залежність: [email protected]. Жодна частина кодової бази її не імпортує. Цей пакет існує виключно для виконання скрипта postinstall, який встановлює міжплатформний RAT (Remote Access Trojan) на машину розробника.
Підготовка була точною. За вісімнадцять годин до випуску axios зловмисник опублікував чисту версію plain-crypto-js під окремим обліковим записом npm, щоб створити історію публікацій та уникнути спрацювання сканерів нових пакетів. Потім з’явився шкідливий 4.2.1. Обидва випуски з’явилися протягом 39 хвилин. Три специфічні для платформи пейлоади були попередньо згенеровані. Шкідливе програмне забезпечення видаляє себе після виконання та замінює чистий package.json, щоб ускладнити криміналістичне розслідування.
StepSecurity, яка виявила компроміс разом із Socket, назвала це однією з найопераційніших складних атак на ланцюжок постачання, коли-небудь задокументованих проти пакету з топ-10 npm.
Захист, який існував на папері
Axios зробив усе правильно. Легітимні релізи 1.x надсилалися через GitHub Actions, використовуючи механізм npm Trusted Publisher на базі OIDC, який криптографічно пов’язує кожну публікацію з перевіреним робочим процесом CI/CD. Проект мав SLSA-атестації походження. За всіма сучасними мірками, стек безпеки виглядав надійно.
Нічого з цього не допомогло. Huntress дослідив робочий процес публікацій і виявив прогалину. Проект все ще передавав NPM_TOKEN як змінну середовища поряд із OIDC-обліковими даними. Коли присутні обидва, npm за замовчуванням використовує токен. Довготривалий класичний токен був реальною автентифікаційною методикою для кожної публікації, незалежно від конфігурації OIDC. Атакувальнику не потрібно було долати OIDC. Він обійшов його. Застарілий токен слугував паралельним шляхом автентифікації, і npm у своїй ієрархії мовчки надавав йому перевагу.
«З мого досвіду роботи в AWS, старі механізми автентифікації часто залишаються», – зазначила Меррітт Беар, CSO в Enkrypt AI та колишній заступник CISO в AWS, в ексклюзивному інтерв’ю VentureBeat. «Сучасні засоби контролю впроваджуються, але якщо старі токени чи ключі не відкликаються, система мовчки надає їм перевагу. Так само, як ми бачили з SolarWinds, де старі скрипти обходили новіші системи моніторингу».
Розробник написав у GitHub після виявлення компромісу: «Я намагаюся отримати підтримку, щоб зрозуміти, як це взагалі сталося. У мене увімкнено 2FA / MFA практично для всього, з чим я взаємодію».
Endor Labs задокументувала криміналістичну різницю. Легітимний [email protected] мав OIDC-походження, запис довіреного видавця та gitHead, що посилався на конкретний коміт. Шкідливий [email protected] не мав нічого з цього. Будь-який інструмент, що перевіряв походження, одразу б помітив цю прогалину. Але перевірка походження є необов’язковою. Жоден шлюз реєстру не відхилив пакет.
Три атаки, сім місяців, одна першопричина
Три компромета ланцюжка постачання npm за сім місяців. Кожен почався зі вкраденого облікового запису розробника.
Черв’як Shai-Hulud атакував у вересні 2025 року. Один обліковий запис розробника, отриманий через фішинг, надав зловмисникам плацдарм, який самовідтворювався в понад 500 пакетах, викрадаючи токени npm, облікові дані хмарних сервісів та секрети GitHub по мірі поширення. CISA випустила консультацію. GitHub переробив всю модель автентифікації npm у відповідь.
Потім, у січні 2026 року, дослідження Koi Security PackageGate виявило шість zero-day вразливостей у npm, pnpm, vlt та Bun, які пробивали захист, впроваджений екосистемою після Shai-Hulud. Цілісність lockfile та блокування скриптів під певними умовами не спрацьовували. Три з чотирьох менеджерів пакетів були виправлені протягом тижнів. npm закрив звіт.
Тепер axios. Викрадений довготривалий токен опублікував RAT через обидві гілки випуску, незважаючи на OIDC, SLSA та всі заходи безпеки, впроваджені після Shai-Hulud.
npm запровадив реальні реформи після Shai-Hulud. Створення нових класичних токенів було припинено, хоча вже існуючі діяли до терміну примусового відкликання. FIDO 2FA стало обов’язковим, гранулярні токени доступу були обмежені сімома днями для публікацій, а довірені публікації через OIDC надали проектам криптографічну альтернативу збереженим обліковим даним. У сукупності ці зміни зміцнили все, що йшло після облікового запису розробника. Що вони не змінили, так це сам обліковий запис. Облікові дані залишалися єдиною точкою відмови.
«Компромета облікових даних є повторюваною темою у всіх зломів npm», – зазначила Беар. «Це не просто проблема слабкого пароля. Це структурна проблема. Без тимчасових облікових даних, примусового MFA або ізольованих середовищ збірки та підписання, доступ розробника залишається слабкою ланкою».
Що npm впровадив проти того, що обійшла ця атака
|
Що потрібно керівникам SOC |
Захист, впроваджений npm |
Проти атаки axios |
Прогалина |
|
Блокувати публікацію вкрадених токенів |
Обов’язково FIDO 2FA. Гранулярні токени, термін дії 7 днів. Класичні токени припинено |
Обхід. Застарілий токен співіснував з OIDC. npm надавав перевагу токену |
Відсутність примусового видалення застарілих токенів при наявності OIDC |
|
Перевіряти походження пакету |
Довірена публікація OIDC через GitHub Actions. SLSA-атестації |
Обхід. Шкідливі версії не мали походження. Публікація через CLI |
Жодний шлюз не відхиляє пакети без походження від проектів, які його мали раніше |
|
Виявляти шкідливе ПЗ до встановлення |
Автоматизоване сканування Socket, Snyk, Aikido |
Частково. Socket помітив через 6 хв. Перші інфекції сталися через 89 секунд |
Час від виявлення до видалення. Сканери виявляють, але видалення з реєстру займає години |
|
Блокувати виконання postinstall |
Рекомендовано –ignore-scripts у CI/CD |
Не примусово. npm виконує postinstall за замовчуванням. pnpm блокує за замовчуванням; npm – ні |
postinstall залишається основним вектором шкідливого ПЗ у кожній великій атаці npm з 2024 року |
|
Фіксувати версії залежностей |
Примусове використання lockfile через npm ci |
Ефективно лише якщо lockfile був зафіксований до компромета. Діапазони caret автоматично вирішувалися |
Діапазони caret є за замовчуванням для npm. Більшість проектів автоматично вирішують до останнього мінорного |
Що робити зараз на вашому підприємстві
Керівники SOC, чиї організації використовують Node.js, повинні ставитися до цього як до активного інциденту, доки не підтвердять безпеку систем. Тригодинне вікно вразливості припало на пікові години розробки в Тихоокеансько-азійському часовому поясі, і будь-який пайплайн CI/CD, який виконував npm install протягом ночі, міг автоматично завантажити скомпрометовану версію.
«Першочерговим завданням є оцінка впливу: які збірки та наступні споживачі отримали скомпрометований пакет?» – зазначила Беар. «Потім стримування, виправлення, і нарешті, прозоре звітування керівництву. Що сталося, що під загрозою, і які заходи запобігатимуть повторенню. Уроки з log4j та event-stream показують, що швидкість та ясність мають таке ж значення, як і виправлення».
-
Перевірте наявність компромета. Шукайте в lockfile та логах CI [email protected], [email protected] або plain-crypto-js. Закріпіть версію [email protected] або [email protected].
-
Припускайте компромет, якщо виявлено. Відновіть уражені машини з відомого безпечного стану. Змініть усі доступні облікові дані: токени 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 на Linux. Якщо знайдено, виконайте повне відновлення.
-
Посильте безпеку надалі. Примусово використовуйте npm ci –ignore-scripts у CI/CD. Вимагайте встановлення лише з lockfile. Відхиляйте пакети без походження від проектів, які його мали раніше. Перевірте, чи співіснують застарілі токени з OIDC у ваших власних робочих процесах публікації.
Прогалина в облікових даних, яку ніхто не закрив
Три атаки за сім місяців. Кожна відрізнялася за виконанням, але мала однакову першопричину. Модель безпеки npm все ще розглядає окремі облікові записи розробників як кінцевий якір довіри. Ці облікові записи залишаються вразливими до викрадення облікових даних, незалежно від того, скільки рівнів безпеки додано нижче.
«ШІ виявляє ризиковані пакети, проводить аудит застарілої автентифікації та прискорює реакцію SOC», – зазначила Беар. «Але люди все ще контролюють облікові дані розробників. Ми знижуємо ризик. Ми його не усуваємо».
Обов’язкова атестація походження, де повністю вимкнено ручну публікацію через CLI, виявила б цю атаку до того, як вона досягла реєстру. Так само, як і обов’язкове багатостороннє підписання, де жоден окремий розробник не може самостійно випустити реліз. Жодне з цих рішень не примусове сьогодні. npm повідомив, що вимкнення токенів за замовчуванням при увімкненні довіреної публікації знаходиться в дорожній карті. Доки це не буде впроваджено, кожен проект, що використовує OIDC поряд із застарілим токеном, має ту саму сліпу зону, що й axios.
Розробник axios зробив те, що просила спільнота. Застарілий токен, про який ніхто не здогадувався, що він досі активний, підірвав усе це.
Як захиститися (Порада ІТ-Блогу): Уникайте використання старих (класичних) токенів для публікації пакетів npm. Якщо ваш проект використовує OIDC або інші сучасні механізми автентифікації для CI/CD, переконайтеся, що застарілі токени для публікації повністю видалені або заблоковані. Регулярно переглядайте та відкликайте будь-які активні токени доступу, які довго не використовувалися.
Джерело новини: venturebeat.com