"EOA only" защита больше не работает
Новые они, конечно, относительно, потому что EIP-7702 был принят еще в мае 2025 с Pectra обновлением сети, но тем не менее
Что изменилось
EIP-7702 позволяет EOA (Externally Owned Account, то, что мы называем кошельком) исполнять код. И это нововведение ломает обратную совместимость для некоторых видов проверок, в частности под удар попадает конструкция
msg.sender == tx.origin
которая использовалась для подтверждения того, что caller является EOA
Такая проверка "EOA only" могла использоваться как защита от вызова функций контрактами и оберегала от reentrancy и flashloan атак
Что случилось
В Notorious Bug Digest #5 от OpenZeppelin описан следующий инцедент.
В августе 2025 года был атакован контракт с неверифицированным кодом на BSC Chain. Это был стейкинг контракт для Wrapped POT токенов с наградами, рассчитывающимися от времени стейкинга.
Цена для POT токенов устанавливалась через PancakeSwap BSC-USD/POT пул.
1. Атакующий деплоит зловредный контракт и делегирует его на EOA адрес через транзакцию типа 7702
2. Атакующий использует EOA для трансфера около 13.9 BNB на свой адрес. Поскольку это трансфер нативного токена, то у привязанного контракта срабатывает fallback функция, которая проходит EOA проверку
3. В этой функции атакующий берет flashloan на 3.5кк $ в BSC-USD токене и покупает в PancakeSwap BSC-USD/POT пуле эквивалентное количество POT токенов, тем самым поднимая цену .
4. Затем атакующий вызывают функцию для стейка токенов, которая считывает цену из пула, подвергнутого манипуляции. Он стейкает примерно 220к POT токенов.
5. Атакующий свапает остальные POT токены обратно в BSC-USD, гасит flashloan, чем приводит цену в норму, а на отправленные ранее 13.9 BNB покупает BSC-USD, чтобы компенсировать купленные 220к POT.
6. Таким же образом был вызван unstake через fallback, который отправил атакующему 3.3кк POT токенов, что стало возможным из-за завышенной оценки застейканных активов. Атакующий смог извлечь 85к$ из протокола
Помимо прочего, в качестве одной из мер защиты, между стейком и анстейком должен был пройти 1 день, но эту защиту хакер обошел. Первую транзакцию он отправил в 2025-08-24 23:59:06 (UTC), а вторую через минуту в 2025-08-25 00:00:14.
Неверифицированный код не служит защитой! Примеры декомпиляции функций контракта представлены в оригинальной статье
https://t.me/web3securityresearch