Эксплойт Kelp — слили $293.0M · разбор · GuardLabs

Технический разбор эксплойта Kelp (2026-04-18). Классификация: Infrastructure. Слили $293.0M на сети Ethereum, Arbitrum.

Технический разбор

Эксплойт протокола Kelp, приведший к потере примерно $293,000,000, был вызван критическим недостатком в его интеграции с протоколом обмена сообщениями LayerZero, а именно в реализации стандарта Omnichain Fungible Token (OFT). Стандарт OFT предназначен для того, чтобы токены могли существовать нативно в нескольких блокчейнах, используя транспортный уровень LayerZero для отправки сообщений (например, «сжечь в сети А, выпустить в сети Б»), которые поддерживают постоянство общего предложения. Уязвимость заключалась не в основной инфраструктуре LayerZero, а в контрактах уровня приложения Kelp, которые ее использовали. Основной причиной стала логическая ошибка в контракте в целевой сети (например, Ethereum), который обрабатывал входящие сообщения из исходной сети (например, Arbitrum). Этот контракт не смог должным образом проверить содержимое или происхождение данных межсетевого сообщения. Этот недосмотр позволил злоумышленнику создать вредоносное сообщение в исходной сети, которое, будучи полученным и выполненным целевым контрактом, вызвало крупный несанкционированный выпуск токена Kelp.

Схема эксплуатации, хотя и не детализированная в публичных отчетах, может быть выведена из характера уязвимости. Предварительными условиями для атаки были наличие у протокола значительной ликвидности, работа в нескольких сетях с использованием стандарта OFT и наличие специфического недостатка валидации в его обработчике межсетевых сообщений. Злоумышленник, вероятно, инициировал процесс, вызвав функцию в контракте-адаптере Kelp OFT в исходной сети (например, Arbitrum) со специально созданной полезной нагрузкой. Эта полезная нагрузка была разработана так, чтобы пройти проверки транспортного уровня LayerZero, но использовать логическую ошибку в принимающем контракте Kelp в целевой сети (Ethereum). Когда ретранслятор LayerZero доставил это сообщение, уязвимый контракт Kelp на Ethereum неверно интерпретировал вредоносную полезную нагрузку, обойдя проверки, которые должны были гарантировать сжигание или блокировку соответствующего количества токенов в исходной сети. Это позволило злоумышленнику вызвать внутреннюю функцию _mint() с произвольным, большим количеством, создав необеспеченные токены на сотни миллионов долларов. Эти новосозданные токены затем были обменены на другие активы в пулах ликвидности, истощив их стоимость до того, как несоответствие было обнаружено и работа протокола приостановлена.

Кто ещё в зоне риска

Любой протокол, реализующий межсетевую функциональность с использованием таких уровней обмена сообщениями, как LayerZero, Axelar, Wormhole или Chainlink CCIP, потенциально подвержен риску, если их интеграция не выполнена с особой тщательностью. Эксплойт Kelp служит суровым напоминанием о том, что безопасность базовой инфраструктуры не гарантирует автоматически безопасность приложения, построенного на ее основе. Основной риск кроется в «швах» между собственной логикой протокола и сторонним уровнем обмена сообщениями. Разработчики часто сосредотачиваются на аудите своей основной бизнес-логики, но могут упускать из виду нюансы и потенциальные векторы атак, возникающие из-за этих сложных интеграций. Распространенные ошибки реализации включают недостаточную проверку исходного адреса и контракта из удаленной сети, доверие к полезной нагрузке сообщения без ее анализа и проверки на соответствие ожидаемым ограничениям, а также наличие слишком разрешительных функций, которые могут быть вызваны межсетевым сообщением.

Протоколам следует быть особенно осторожными с любой функцией, которая существенно изменяет состояние (например, mint, burn, изменение критических параметров) и может быть вызвана через межсетевое сообщение. Ключевым признаком риска, на который следует обращать внимание во время аудита или проверки кода, является отсутствие строгой, основанной на путях валидации. Например, сообщение от контракта X в сети A должно иметь возможность вызывать только определенное, узко определенное действие в контракте Y в сети B. Если принимающий контракт допускает произвольные вызовы функций или не контролирует жестко параметры, передаваемые из межсетевого сообщения, это создает значительную уязвимость.

Уроки для разработчиков и пользователей

Этот инцидент преподносит несколько критически важных уроков для экосистемы DeFi. Для разработчиков смарт-контрактов основной вывод — относиться ко всем данным из другой сети как к недоверенным. Вот конкретные, действенные шаги:

• Строгая проверка полезной нагрузки: Никогда не доверяйте целостности данных межсетевого сообщения. Принимающий контракт должен тщательно анализировать и проверять каждый параметр. Для OFT это означает проверку того, что сообщение о выпуске соответствует легитимному событию сжигания в доверенном исходном контракте.
• Контроль доступа на основе путей: Используйте функции LayerZero (или их эквиваленты в других протоколах), чтобы гарантировать, что только определенный, внесенный в белый список контракт в исходной сети может вызывать определенную функцию в целевой сети. Это не позволит злоумышленнику использовать посторонний контракт для отправки вредоносных сообщений.
• Тестирование инварианта предложения: Важнейшим инвариантом для любого межсетевого токена является то, что общее предложение во всех сетях остается постоянным (или изменяется только через предназначенные для этого механизмы). Это должно быть основной частью набора тестов. Автоматизированные тесты должны симулировать межсетевые переводы и утверждать, что totalSupply_chainA + totalSupply_chainB остается неизменным.
• Мониторинг в реальном времени: Если бы был внедрен сервис, подобный Web-Audit Guardian от GuardLabs, он мог бы немедленно выдать предупреждение о аномальном событии выпуска на миллионы долларов, что потенциально позволило бы команде приостановить контракты и значительно раньше смягчить ущерб.

Для пользователей и поставщиков ликвидности этот эксплойт подчеркивает увеличенную поверхность атаки многосетевых протоколов. Прежде чем вносить средства, оцените документацию проекта по его модели межсетевой безопасности. Ищите аудиты, в которых конкретно названы и проанализированы контракты-адаптеры OFT/межсетевые, а не только основная логика протокола. Поймите, что хотя межсетевые возможности предлагают большую пользу, они также вводят новые и сложные риски, которых нет в односетевых приложениях.

Для алгоритмических трейдеров этот инцидент демонстрирует форму рыночного риска, уникальную для DeFi. Внезапная, массовая инфляция предложения токена в одной сети может сделать арбитражные модели неэффективными и привести к огромным убыткам. Системы управления рисками должны включать потоки данных из блокчейна, которые отслеживают аномальные изменения предложения, особенно для токенов с межсетевым присутствием. Подобный эксплойт может вызвать полную потерю привязки стоимости токена к его предполагаемому обеспечению, мгновенно сделав его бесполезным.

Частые вопросы

Метаданные эксплойта