Эксплойт Polymarket: утечка ключа, а не уязвимость контракта
22 мая 2026 года on-chain следователь ZachXBT зафиксировал вывод средств с одного из кошельков Polymarket. Первоначальные оценки составили около 520 тыс. долларов. К моменту, когда команда подтвердила детали, цифра приблизилась к 660-700 тыс. долларов. Без повторного входа. Без манипуляций с оракулом. Без изощрённой хореографии с флэш-займами. Просто приватный ключ, оказавшийся там, где ему быть не следовало.
Эксплойт Polymarket не затронул ту часть стека, которую все нанимают Trail of Bits и OpenZeppelin проверять. Удар пришёлся по внутреннему пополняющему кошельку, операционному аккаунту, используемому для финансирования вознаграждений и поддержания работы платформы. Тому виду кошельков, который никогда не попадает в область аудита, потому что это не смарт-контракт. Это ключ, лежащий на чьей-то инфраструктуре.
В этом и заключается неудобная часть истории. После года, когда заголовки пестрели новостями о мостах и неправильных конфигурациях DVN, самый финансируемый рынок предсказаний в мире был слит через самый банальный вектор атаки из всех возможных.
Что на самом деле произошло в Polygon
Слитый аккаунт был операционным кошельком, а не пользовательскими средствами в основных контрактах протокола. По данным CoinDesk, ZachXBT зафиксировал вывод около 520 тыс. долларов, и команда Polymarket заявила, что средства клиентов в безопасности. Злоумышленник вывел POL и другие активы с кошелька в Polygon, после чего сделал то, что злоумышленники делают всегда, перевёл средства через мост и рассредоточил их прежде, чем кто-либо успел что-либо заморозить.
По данным Decrypt, сумма ближе к 700 тыс. долларов; издание идентифицировало его именно как внутренний пополняющий кошелёк. Расхождение в цифрах в первые 24 часа нормально; механизм атаки сомнений не вызывает. Кто-то завладел ключом.
Это эксплойт Polygon POL лишь в том смысле, что POL был активом, находившимся в кошельке. Чейн не подвёл. Контракт не подвёл. Подвело хранение одного операционного ключа.
Почему адаптер UMA CTF не был причиной
И это никак с ним не связано.
Думаю, это деталь, которую люди склонны игнорировать, хотя не стоит. Слой смарт-контрактов выдержал. Оракул выдержал. Сломалось другое: кошелёк, которым управляет человек с ключом, доступным человеку (или CI-пайплайну, или горячему сервису подписи). Весь бычий рынок мы укрепляли части системы с формальной верификацией и игнорировали те, что хранятся в .env-файле.
Операционные ключи сегодня и есть главная поверхность атаки
Вот паттерн инцидентов 2026 года. Solidity становится лучше. Аудиторы хорошо делают свою работу. Формальные методы отлавливают баги с повторным входом, которые раньше опустошали девятизначные суммы. Поэтому атакующие сместились.
Они перешли к мягким тканям:
- Горячие кошельки для вознаграждений, пополнения газа и маркетмейкинга.
- Ключи деплоера, которые так и не сменили после запуска.
- Подписанты мультисигов, использующие один ноутбук для подписания транзакций и веб-сёрфинга.
- Секреты CI/CD, способные подписывать транзакции в продакшне.
Ничего из этого нет в отчёте об аудите. Когда я оцениваю безопасность регулируемой биржи, проверка контрактов занимает от силы треть работы. Остальное: HSM-модули, разграничение подписантов, документация ключевых церемоний и глубоко непривлекательный вопрос "кто может перевести деньги в три ночи и что ему помешает". Именно здесь большинство команд уязвимы.
Тот же урок, что в случае с Kelp DAO и LayerZero: $292 млн пропали не из-за бага в контракте, а из-за неверной конфигурации на операционном уровне. Разный механизм, одна причина: скучная часть, которую никто не аудирует.
Каким должен был быть операционный кошелёк на $660 тыс.
Если один ключ может перевести $660 тыс., это архитектурное решение, а не невезение. Вот несколько вещей, которые должны быть само собой разумеющимися для любого операционного кошелька, хранящего значимую сумму:
- Лимиты расходов в самой логике кошелька. Кошелёк для пополнения вознаграждений не должен иметь возможности отправить весь баланс в одной транзакции. Ограничьте это на уровне блокчейна.
- Пороговая подпись для сумм выше минимума. Небольшие автоматические выплаты могут быть горячими. Всё, что превышает, скажем, $10 тыс., должно требовать второй подписи. Safe-мультисиг с низким порогом для крупных переводов не представляет сложности.
- Изоляция ключа от среды приложения. Ключ подписи операционного кошелька никогда не должен находиться там, где его могут прочитать код приложения, зависимости или скомпрометированный CI-runner.
- Мониторинг с уведомлением специалиста при аномальном оттоке средств. ZachXBT обнаружил это раньше, чем команда сообщила об инциденте. Ваши собственные оповещения должны опережать стороннего наблюдателя за мемпулом.
Ничего нового здесь нет. Это то, что отбрасывают, когда команда торопится с выпуском, а кошелёк считается «просто для вознаграждений».
Пробел в стеке аудита, за который никто не отвечает
Более глубокая проблема носит внутренний, ведомственный характер. Безопасность смарт-контрактов имеет чёткого владельца: аудиторскую компанию. Безопасность операционных ключей имеет... того, кто настраивал кошелёк, как правило, в условиях сжатых сроков, и к которой зачастую больше не возвращаются. Я писал об этом пробеле в контексте разрушенного стека аудита DeFi: сертификация охватывает контракты и останавливается на их границе. Всё операционное находится вне области охвата и вне поля зрения.
Пока регулятор или страховщик не заставит выделить операционную безопасность в отдельную статью с ответственным, это будет повторяться. Операционная безопасность DeFi в 2026 году находится примерно там, где безопасность смарт-контрактов была в 2019-м: все понимают её важность, никто за неё не отвечает, она финансируется в последнюю очередь.
Polymarket справится. $660 тыс. — переносимая потеря для платформы их масштаба, и надо отдать им должное: они отреагировали быстро и прозрачно. Но у следующей команды, с которой это случится, может не оказаться достаточного запаса прочности, чтобы выдержать удар. Компрометация, которая опустошит казну, а не кошелёк для вознаграждений, уже на подходе, и это будет не баг в Solidity. Это будет ключ на чьём-то ноутбуке.