Що насправді ховалося за зламом Axios і які його масштаби

Нещодавно, як ви всі знаєте, стався злам популярної JavaScript-бібліотеки Axios. Зловмисники додали в неї шкідливий код через залежність під назвою plain-crypto-js.

Здавалося б, проблему вирішили досить оперативно. Зараженими виявилися лише дві версії, адміністратори реєстру npm оперативно їх видалили, і більшість команд просто перевірили свої проєкти та заспокоїлися. Але подальший аналіз показав, що наслідки атаки були значно цікавішими.

«Безпека не буває зручною»

Один раз я якось почув фразу: «Безпека ніколи не буває зручною». І так воно і є. В цьому випадку справа не лише в самому зламі, а в тому, як сучасні програми завантажують свої компоненти. Розробники рідко вказують точну версію кожної бібліотеки і замість цього у файлах конфігурації зазвичай прописують так звані діапазони версій. Умовно:

"axios": "^1.13.5"

Цей маленький символ ^ перед номером версії, як ви знаєте, працює як інструкція для системи:

«Завантаж будь-яку найсвіжішу версію, яка є більшою або дорівнює 1.13.5, але менша за версію 2.0.0».

Це робиться навмисно, щоб не зламати сумісність і автоматично отримувати дрібні оновлення безпеки.

Коли хакери опублікували заражену версію [email protected], вона без жодних проблем стала тією самою найсвіжішою версією для мільйонів запитів. Програмам навіть не потрібно було оновлювати код чи отримувати дозвіл від розробника. Будь-яка команда на кшталт звичайного npm install, виконана без жорсткої фіксації залежностей, просто підтягувала вірус.

Не використовуєте Axios? Все одно перевіртеся

Що робить цю атаку ще більш цікавою, так це те, що розробникам навіть не обов’язково було мати Axios у своєму проєкті. Достатньо було використовувати інструменти, які покладаються на нього десь глибоко під капотом. Наприклад, коли хтось створював новий проєкт простою командою npx gatsby new, ця утиліта автоматично завантажувала заражений пакет у фоновому режимі.

Багато хто вважає файли фіксації залежностей, такі як package-lock.json, надійним захистом. Але це не завжди так. Коли система завантажує щось нове або виконує скрипти динамічно через утиліту npx, файли фактично ігноруються системою при завантаженні нових компонентів. Деякі девелопери намагалися убезпечити себе, напряму вказуючи версію інструменту під час запуску (наприклад, виконуючи npx [email protected]). Однак сама утиліта була зафіксована, а її внутрішні транзитивні залежності все одно завантажувалися динамічно згідно з тими ж гнучкими діапазонами.

Щоразу під час виклику команди через npx відбувається нове звернення до реєстру. Якщо саме в цю секунду там лежить вірус, він миттєво завантажується, виконує свій код і зникає. Журнали сервера покажуть, що скрипт виконався успішно. Оскільки заражену версію вже видалили, повторні перевірки сьогодні дадуть абсолютно чистий результат. Зрозуміти, чи була ваша система зламана вчора, практично неможливо.

Загалом, у критичних та автоматизованих середовищах розробникам радять відмовитися від команди npm install на користь суворої npm ci, яка жорстко дотримується файлів блокування і не намагається завантажити щось нове.

Також спеціалісти замість простого старту програм тепер радять примусово переводити систему в автономний режим та забороняти будь-які завантаження з інтернету на льоту. Це робиться за допомогою спеціальних прапорців:

npx --no --offline

У складних середовищах, де пакети зберігаються в окремих папках, команди стають ще довшими і виглядають якось так:

 npx --no --offline --include-workspace-root --workspace /path/to/ci-workspace. 

Як альтернативу постійному написанню цих команд, розробники можуть додати налаштування npm_config_yes=false у конфігураційний файл .npmrc або як змінну середовища NPM_CONFIG_YES=false.

А ще фахівці радять приділити увагу сучасним AI-агентам та серверам MCP, які часто самостійно запускають скрипти. Їхні файли конфігурації тепер мають виглядати як суворі інструкції з безпеки. Ось приклад такої конфігурації з оригінального звіту:

{
  "mcpServers": {
    "playwright": {
      "command": "npx",
      "args": [
        "--include-workspace-root",
        "--workspace $HOME/mcp",
        "--no",
        "--offline",
        "@playwright/[email protected]"
      ]
    }
  }
}

Підписуйтеся на Telegram-канал «DOU #tech», щоб не пропустити нові технічні статті