Атака на ланцюжок постачання: npm-пакет з мільйоном завантажень крав паролі розробників

Мільйон завантажень — і вкрадені паролі

В квітні 2026 року дослідники безпеки виявили щось тривожне: популярний npm-пакет, який щомісяця завантажували понад мільйон проєктів по всьому світу, містив прихований шкідливий код. Цей код непомітно збирав облікові дані — паролі, API-ключі, токени авторизації — і передавав їх на сервер зловмисників. Сотні тисяч розробників, компаній і сервісів опинились під загрозою компрометації, навіть не підозрюючи про це.

Це не перший і точно не останній випадок. Атаки на ланцюжок постачання програмного забезпечення (supply chain attacks) стали одним із найнебезпечніших інструментів кіберзловмисників у 2020-х роках — саме тому, що жертви роблять все технічно правильно, але все одно потрапляють під удар. Вони встановлюють пакети з офіційного реєстру, перевіряють хеші, оновлюють залежності вчасно — і все одно виявляються зламаними.

Щоб зрозуміти, чому це відбувається і як себе захистити, потрібно розібратись у механізмах, якими зловмисники проникають у найбільші відкриті екосистеми програмного забезпечення у світі.

Що таке атака на ланцюжок постачання?

Ланцюжок постачання програмного забезпечення — це весь шлях від вихідного коду до кінцевого продукту: репозиторії, залежності, CI/CD-пайплайни, пакетні менеджери, інфраструктура побудови. Атака на ланцюжок постачання — це коли зловмисник не зламує вашу систему напряму, а компрометує одного з постачальників, чиє програмне забезпечення ви використовуєте.

Уявіть: ви будуєте будинок і купуєте цеглу від надійного постачальника, якому довіряєте роками. Але хтось непомітно заклав у частину цегли вибухівку ще на заводі. Ви не зламали жодного замка, не порушили жодного правила безпеки — але ваш будинок все одно підірваний зсередини.

Саме такий механізм: довіра до постачальника стає вектором атаки. Чим популярніший пакет — тим більш привабливою ціллю він є. Мільйон завантажень на місяць означає мільйон потенційних жертв при успішній компрометації.

Гучні прецеденти: від SolarWinds до XZ Utils

Атаки на ланцюжок постачання існують давно, але за останні роки вийшли на якісно новий рівень складності та масштабу:

• SolarWinds (2020) — хакери, пов’язані з російськими спецслужбами (група Cozy Bear/APT29), впровадили бекдор SUNBURST у оновлення популярного IT-інструменту SolarWinds Orion. Під удар потрапили близько 18 000 організацій, зокрема Міністерство фінансів США, Пентагон, підрядники ядерного комплексу. Атака залишалась непоміченою дев’ять місяців.
• event-stream (2018) — npm-пакет із 2 млн завантажень на тиждень. Зловмисник запропонував допомогу у підтримці “покинутого” пакету, отримав права мейнтейнера, додав шкідливий залежний модуль flat-map-stream, спрямований на конкретний біткоїн-гаманець Copay.
• Codecov bash uploader (2021) — зловмисники змінили скрипт завантаження на офіційному сервері Codecov. Тисячі CI/CD-систем автоматично виконували скомпрометований скрипт і надсилали змінні середовища (з секретами!) зловмисникам. Серед жертв — Twitch, Atlassian, Rapid7.
• PyPI malware (2023-2025) — постійний потік шкідливих пакетів у Python Package Index: тайпсквотинг (пакети з назвами, схожими на популярні), пакети з прихованими кейлогерами та стілерами. За даними Socket, у 2024 році виявлено понад 14 000 шкідливих пакетів у PyPI.
• XZ Utils backdoor (2024) — найбільш витончена операція. Зловмисник під псевдонімом Jia Tan роками будував довіру в open-source спільноті, поступово ставав ключовим контриб’ютором і мейнтейнером XZ Utils — базової утиліти стиснення, встановленої на сотнях мільйонів Linux-систем. Бекдор у SSH-демоні міг надати несанкціонований доступ до будь-якого сервера із скомпрометованою версією. Виявлений лише завдяки нетиповій уважності одного розробника Microsoft — Андреша Фройнда — за кілька тижнів до широкого розповсюдження.

Квітневий інцидент 2026 року вписується в цю закономірність. Мільйон завантажень — це не просто статистика. Це мільйон проєктів, кожен із яких потенційно передав зловмисникам свої секрети: ключі AWS, токени баз даних, паролі від платіжних систем.

Як це технічно працює в npm та pip

Пакетні менеджери npm (Node.js) та pip (Python) — серце сучасної розробки. Типовий JavaScript-проєкт може мати сотні прямих залежностей і тисячі транзитивних (залежності залежностей). Поверхня атаки — колосальна.

Головні механізми впровадження шкідливого коду:

• Тайпсквотинг — публікація пакету з назвою, схожою на популярний: reqeusts замість requests, coIors (велика I замість l) замість colors. Розробник помиляється при наборі — і отримує шкідливу версію.
• Захоплення акаунту мейнтейнера — зламати обліковий запис людини, яка підтримує популярний пакет, і опублікувати нову версію із вбудованим бекдором. Саме за таким сценарієм, найімовірніше, розгортався квітневий інцидент 2026 року.
• Dependency confusion — атака на внутрішні реєстри пакетів компаній. Якщо компанія використовує приватний npm-реєстр для власних пакетів, зловмисник публікує пакет із тією самою назвою у публічному реєстрі з вищим номером версії. Npm завантажить публічну шкідливу версію замість приватної легітимної.
• Повільне отруєння — метод XZ Utils. Зловмисник роками будує репутацію надійного контриб’ютора, поступово отримує привілеї мейнтейнера, і лише тоді впроваджує бекдор — коли всі вже довіряють.
• Шкідливі lifecycle scripts — npm дозволяє пакетам виконувати скрипти при встановленні (preinstall, postinstall). Зловмисники ховають у них код, що запускається на машині розробника ще до того, як він відкриє текстовий редактор.

Що крадуть і куди відправляють

У квітневому інциденті шкідливий пакет збирав кілька категорій чутливих даних:

• Змінні середовища (.env файли) — звідти витягуються API-ключі AWS, рядки підключення до баз даних, ключі платіжних систем Stripe/PayPal
• SSH-ключі з директорії ~/.ssh/
• Збережені облікові дані git (часто містять токени GitHub/GitLab)
• Токени NPM та pip — що дозволяє ланцюгову атаку: вкравши токен, зловмисник може опублікувати шкідливу версію вашого власного пакету

Дані передавались через HTTPS на зовнішній сервер — зашифрований трафік, що не виглядає підозріло для більшості мережевих фільтрів. Пакет чекав кілька хвилин після встановлення і лише тоді виконував ексфільтрацію — щоб обійти пісочниці автоматичного аналізу безпеки.

Вкрадені ключі AWS можуть надати повний доступ до хмарної інфраструктури компанії. Компрометований npm-токен дозволяє опублікувати нову шкідливу версію вашого власного пакету — і зараза пошириться на ваших користувачів. Це не просто крадіжка паролів — це потенційний крах усього цифрового бізнесу.

Як ми детально розглядали у матеріалі про Palantir та корпоративне стеження, збір даних без відома жертви став системним явищем — але якщо Palantir робить це відкрито і за державними контрактами, то атаки на ланцюжок постачання — це крадіжка через black box, непомітна навіть для досвідченого розробника.

Як перевірити свій проєкт: практичний чеклист

1. npm audit та pip-audit

# Для Node.js/npm
npm audit
npm audit --audit-level=high

# Для Python
pip install pip-audit
pip-audit

# Перевірка конкретного пакету
pip-audit -r requirements.txt

npm audit перевіряє відомі вразливості з бази даних GitHub Advisory Database. Але це не захищає від нових атак — бекдор у свіжоскомпрометованому пакеті ще не буде у базі даних CVE протягом кількох годин або днів після публікації.

2. Socket.dev — аналіз поведінки пакетів

Socket (socket.dev) аналізує npm-пакети не лише на відомі CVE, але й на підозрілу поведінку: мережеві з’єднання, виконання shell-команд, читання змінних середовища, доступ до файлової системи поза межами проєкту. Саме те, що виявляє атаку квітневого типу.

# Встановити CLI
npm install -g @socket/cli

# Сканувати проєкт
socket report create

# Перевірити конкретний пакет
socket npm [package-name]

3. Перевірка хешів та lockfiles

Завжди комітьте package-lock.json або yarn.lock. Ці файли фіксують точні версії та хеші всіх залежностей. При наступному встановленні npm перевіряє хеш — підмінений пакет не пройде перевірку.

# Встановлення з суворою перевіркою lockfile (для CI/CD)
npm ci

# Python: заморозити залежності з хешами
pip install pip-tools
pip-compile --generate-hashes requirements.in

4. Аналіз lifecycle scripts

Перевіряйте, чи не виконує пакет підозрілих дій при встановленні:

# Переглянути lifecycle scripts пакету
cat node_modules/[package-name]/package.json | grep -A 10 '"scripts"'

# Заборонити lifecycle scripts при встановленні (обережно!)
npm install --ignore-scripts

# Дізнатися, хто встановив певний пакет (по ланцюгу залежностей)
npm why [package-name]

5. Dependabot та Renovate

GitHub Dependabot та Renovate Bot автоматично відстежують оновлення залежностей і створюють pull request при виявленні вразливостей або доступних оновлень. Для критичних проєктів — обов’язковий інструмент автоматизації безпеки.

6. Закріплення версій та моніторинг змін мейнтейнерів

Закріплюйте точні версії залежностей ("axios": "1.7.2" замість "^1.7.2"). Перед оновленням перевіряйте: чи не змінився власник пакету?

# Перевірити список власників npm-пакету
npm owner ls [package-name]

# Переглянути повну інформацію та дату останньої публікації
npm info [package-name]

# Переглянути список контриб'юторів та зміни у GitHub
# Завжди перевіряйте diff оновлення пакету перед merge PR

Пакет із нульовою активністю роками — і раптова нова версія — тривожний сигнал. Саме такий патерн характерний для атаки з “повільним захопленням” за схемою XZ Utils.

Захист середовища розробки від ексфільтрації

Навіть якщо шкідливий пакет потрапив на машину розробника, можна обмежити збитки архітектурно:

• Менеджер секретів замість .env — не зберігайте API-ключі та паролі у .env у кореневій директорії проєкту. Використовуйте HashiCorp Vault, 1Password Secrets Automation, AWS Secrets Manager або Infisical.
• Принцип мінімальних привілеїв для ключів — кожен API-ключ повинен мати доступ лише до того, що справді потрібно. Ключ для читання S3 не повинен мати права на запис.
• Ізольовані середовища розробки — Docker, nix-shell або VS Code devcontainers для кожного проєкту. Шкідливий пакет у контейнері не матиме доступу до вашого домашнього каталогу з SSH-ключами.
• Моніторинг мережевих з’єднань — незвичні outbound-з’єднання з машини розробника у неробочий час можуть вказувати на компрометацію. Little Snitch (macOS), OpenSnitch (Linux) — інструменти для моніторингу.
• Ротація ключів — регулярно міняйте API-ключі та токени, навіть якщо підозрілого нічого не помітили.

Якщо ви дбаєте про приватність і безпеку системи загалом, варто ознайомитись з Tails OS 7.7 — операційною системою, розробленою для захисту від стеження на системному рівні. Але від атаки через скомпрометований npm-пакет Tails не захищає — тут потрібні процесуальні заходи.

Чому “відкритий код” не означає “перевірений код”

Поширена хибна думка: якщо вихідний код доступний — він перевірений спільнотою. Насправді більшість npm-пакетів ніхто ніколи ретельно не читав. Розробники довіряють числу завантажень, зіркам на GitHub та тому факту, що пакет “всі використовують”.

Згідно з дослідженнями Socket, 94% npm-пакетів взагалі не проходять будь-якого аудиту безпеки перед публікацією. Npm-реєстр — це відкрите сховище, куди будь-хто може завантажити що завгодно. PyPI — аналогічно.

Проєкт XZ Utils показав: навіть найбільш технічно уважна спільнота може роками не помічати зловмисника, якщо той терпеливо будує репутацію. Сьогодні open source стає полем для державних акторів — спецслужби та організовані хакерські групи інвестують у довгострокові атаки через популярні репозиторії.

Це частина ширшої картини: архітектура цифрового стеження поширюється не лише через державні системи і корпоративні продукти, але й через рядок npm install, яким розробники користуються по десятки разів на день.

Практичний план захисту: короткий підсумок

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

Обов’язковий мінімум:

• Завжди комітьте package-lock.json / yarn.lock / requirements.txt з хешами
• Регулярно запускайте npm audit та pip-audit у CI/CD
• Підключіть Socket.dev або аналогічний інструмент поведінкового аналізу пакетів
• Не зберігайте секрети у кореневих директоріях проєктів — використовуйте менеджери секретів
• Ставтесь із підозрою до пакетів, де раптово змінився мейнтейнер або з’явилась нова версія після тривалої мовчанки
• Ізолюйте середовища розробки через Docker або devcontainers
• Увімкніть Dependabot або Renovate для автоматичного моніторингу

В епоху, де Bluetooth-трекери стали зброєю стеження у фізичному світі, а npm-пакети — у цифровому, здорова параноя є не слабкістю, а необхідністю. Безпека залежностей — це постійна практика, а не галочка у чеклисті.

• Share on Bluesky
• Share on Facebook
• Share on LinkedIn
• Email this Page
• Print this Page
• Share on Reddit
• Share on Tumblr
• Share on WhatsApp
• Share on Viber
• Share on Threads
• Share on Telegram
• Share on X

Незалежні новини від News Group – Дякує Вам за підтримку та активність, ми цінуємо кожного, та хвилюємось за Вас, якщо ви бажаєте підтримати наш проєкт або додати пропозицію.

Для звʼязку переходьте за посиланнями:

• Mastodon
• Bluesky
• LinkedIn
• X

Приєднуйтесь до соціальної мережі для інвесторів та підприємців VIR.GROUP — live-стрічка проектів, ескроу-угоди, VIR AI аналітика і Matrix-чат.

VIR.GROUP is available on Google Play VIR.GROUP is available on the App Store

Наша захищена Мережа Mastodon