Back to Details

solidity-audit

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Solidity Security Audit Checklist

Solidity安全审计清单

Language Rule

语言规则

  • Always respond in the same language the user is using. If the user asks in Chinese, respond in Chinese. If in English, respond in English.
Usage: This skill is for security audits and code reviews. It is NOT auto-invoked — call 
/solidity-audit
when reviewing contracts for vulnerabilities.
  • 始终使用与用户提问相同的语言回复：如果用户用中文提问就用中文回复，用英文提问就用英文回复。
使用说明：本技能用于安全审计和代码审查，不会自动触发——审查合约漏洞时调用 
/solidity-audit
命令即可。

Contract-Level Vulnerabilities

合约层面漏洞

1. Reentrancy

1. 重入（Reentrancy）

VariantDescriptionCheck
Same-functionAttacker re-enters the same function via fallback/receiveAll external calls after state updates (CEI pattern)?
Cross-functionAttacker re-enters a different function sharing stateAll functions touching shared state protected by 
nonReentrant
?
Cross-contractAttacker re-enters through a different contract that reads stale stateExternal contracts cannot read intermediate state?
Read-onlyView function returns stale data during mid-execution stateNo critical view functions used as oracle during state transitions?
Case: GMX v1 (Jul 2025, $42M) — reentrancy in GLP pool on Arbitrum, attacker looped withdrawals to drain liquidity.
变体描述检查项
同函数重入攻击者通过fallback/receive函数重入同一个函数所有外部调用都在状态更新之后执行（遵循CEI模式）？
跨函数重入攻击者重入共享状态的其他函数所有操作共享状态的函数都使用
nonReentrant
防护？
跨合约重入攻击者通过读取过时状态的其他合约发起重入外部合约无法读取中间状态？
只读重入视图函数在执行过程中返回过时的状态数据状态转换过程中不会把关键视图函数用作预言机？
案例：GMX v1 (2025年7月, 4200万美元) — Arbitrum链上GLP池存在重入漏洞，攻击者循环发起提款耗尽流动性。

2. Access Control

2. 访问控制（Access Control）

CheckDetail
Missing modifierEvery state-changing function has explicit access control?
Modifier logicModifier actually reverts on failure (not just empty check)?
State flagAccess-once patterns properly update storage after each user?
Admin privilege scopeOwner powers are minimal and time-limited?
Case: Bybit (Feb 2025, $1.4B) — Safe{Wallet} UI injected with malicious JS, hijacked signing process. Not a contract flaw, but access control at the infrastructure layer.
检查项详情
缺少修饰符所有修改状态的函数都有明确的访问控制？
修饰符逻辑修饰符校验失败时会正确回滚，而非仅做空检查？
状态标记单次访问模式会在每个用户访问后正确更新存储？
管理员权限范围所有者权限最小化且有时间限制？
案例：Bybit (2025年2月, 14亿美元) — Safe{Wallet} UI被注入恶意JS，签名过程被劫持。不属于合约漏洞，属于基础设施层面的访问控制问题。

3. Input Validation

3. 输入校验（Input Validation）

CheckDetail
Zero addressAll address params reject 
address(0)
?
Zero amountFund transfers reject zero amounts?
Array boundsPaired arrays validated for matching length?
Arbitrary callNo unvalidated 
address.call(data)
where attacker controls 
data
?
Numeric boundsInputs bounded to prevent dust attacks or gas griefing?
检查项详情
零地址校验所有地址参数都拒绝
address(0)
？
零金额校验资金转账操作拒绝零金额？
数组边界校验成对数组的长度匹配？
任意调用校验不存在攻击者可控制
data
的未校验
address.call(data)
？
数值边界校验输入有边界限制，避免粉尘攻击或gas griefing？

4. Flash Loan Attacks

4. 闪电贷攻击（Flash Loan Attacks）

VariantMechanismDefense
Price manipulationFlash-borrow → swap to move price → exploit price-dependent logic → repayTWAP oracle with min-liquidity check
GovernanceFlash-borrow governance tokens → vote → repay in same blockSnapshot voting + minimum holding period + timelock ≥ 48h
LiquidationFlash-borrow → manipulate collateral value → trigger liquidationMulti-oracle price verification + circuit breaker
Combo (rounding)Flash-borrow → manipulate pool → micro-withdrawals exploit rounding → repayMinimum withdrawal amount + virtual shares
Cases:
变体攻击机制防护方案
价格操纵闪电贷借入→交易拉抬/压低价格→利用依赖价格的逻辑获利→还款带最低流动性校验的TWAP预言机
治理攻击闪电贷借入治理代币→投票→同一个块内还款快照投票+最低持有周期+≥48小时的时间锁
清算攻击闪电贷借入→操纵抵押品价值→触发清算多预言机价格校验+断路器
组合攻击（舍入误差）闪电贷借入→操纵池子→小额提款利用舍入误差获利→还款最低提款金额+虚拟份额
案例:

5. Oracle & Price

5. 预言机与价格（Oracle & Price）

CheckDetail
Single oracle dependencyUsing multiple independent price sources?
Stale priceChecking 
updatedAt
timestamp and rejecting old data?
Spot price usageNever using raw AMM reserves for pricing?
Minimum liquidityOracle reverts if pool reserves below threshold?
Price deviationCircuit breaker if price moves beyond threshold vs last known?
Chainlink round completenessChecking 
answeredInRound >= roundId
?
Case: Cream Finance (Oct 2021, $130M) — attacker manipulated yUSD vault price by reducing supply, then used inflated collateral to drain all lending pools.
检查项详情
单一预言机依赖使用多个独立的价格数据源？
价格过时校验检查
updatedAt
时间戳，拒绝旧数据？
现货价格使用不会直接使用AMM原始储备量定价？
最低流动性校验池子储备低于阈值时预言机回滚？
价格偏差校验价格较上一次记录超出阈值时触发断路器？
Chainlink轮次完整性校验检查
answeredInRound >= roundId
？
案例：Cream Finance (2021年10月, 1.3亿美元) — 攻击者通过减少供给操纵yUSD金库价格，然后使用 inflated 的抵押品耗尽所有借贷池。

6. Numerical Issues

6. 数值问题（Numerical Issues）

TypeDescriptionDefense
Primitive overflow
uint256 a = uint8(b) + 1
— reverts if b=255 on Solidity ≥0.8		Use consistent types, avoid implicit narrowing
Truncation
int8(int256Value)
— silently overflows even on ≥0.8		Use 
SafeCast
library for all type narrowing
Rounding / precision loss
usdcAmount / 1e12
always rounds to 0 for small amounts		Multiply before divide; check for zero result
Division before multiplication
(a / b) * c
loses precision		Always 
(a * c) / b
Case: Bunni (Sep 2025, $8.4M) — rounding errors in micro-withdrawals exploited via flash loan.
类型描述防护方案
基础类型溢出
uint256 a = uint8(b) + 1
— Solidity≥0.8版本下b=255时会回滚		使用统一类型，避免隐式类型收窄
截断溢出
int8(int256Value)
— 即使≥0.8版本也会静默溢出		所有类型收窄操作使用
SafeCast
库
舍入/精度损失小额数值下
usdcAmount / 1e12
总是舍入为0		先乘后除；检查结果不为零
先除后乘
(a / b) * c
会损失精度		始终使用
(a * c) / b
案例：Bunni (2025年9月, 840万美元) — 小额提款的舍入误差被攻击者通过闪电贷利用。

7. Signature Issues

7. 签名问题（Signature Issues）

TypeDescriptionDefense
ecrecover returns address(0)Invalid sig returns 
address(0)
, not revert		Always check 
recovered != address(0)
Replay attackSame signature reused across txs/chainsInclude 
chainId
+ 
nonce
+ 
deadline
in signed data
Signature malleabilityECDSA has two valid (s, v) pairs per signatureUse OpenZeppelin 
ECDSA.recover
(enforces low-s)
Empty loop bypassSignature verification in for-loop, attacker sends empty arrayCheck 
signatures.length >= requiredCount
before loop
Missing msg.sender bindingProof/signature not bound to callerAlways include 
msg.sender
in signed/proven data
类型描述防护方案
ecrecover返回零地址无效签名返回
address(0)
而非回滚		始终检查
recovered != address(0)
重放攻击同一签名可在多笔交易/多条链上复用签名数据包含
chainId
+
nonce
+
deadline
签名延展性ECDSA每个签名对应两个有效的(s, v)对使用OpenZeppelin的
ECDSA.recover
（强制低s值）
空循环绕过签名校验放在for循环中，攻击者传入空数组绕过循环前检查
signatures.length >= requiredCount
缺少msg.sender绑定证明/签名未与调用者绑定签名/证明数据始终包含
msg.sender

8. ERC20 Compatibility

8. ERC20兼容性（ERC20 Compatibility）

IssueDescriptionDefense
Fee-on-transfer
transfer(100)
may deliver <100 tokens		Check balance before/after, use actual received amount
Rebase tokensToken balances change without transfersNever cache external balances; always read live
No bool returnSome tokens (USDT) don't return bool on transferUse 
SafeERC20.safeTransfer
ERC777 hooksTransfer hooks can trigger reentrancyUse 
ReentrancyGuard
on all token-receiving functions
Zero-amount transfer
transferFrom(A, B, 0)
— address poisoning		Reject zero-amount transfers
Approval raceChanging allowance from N to M allows spending N+MUse 
safeIncreaseAllowance
/ 
safeDecreaseAllowance
问题描述防护方案
转账扣费
transfer(100)
实际到账可能少于100个代币		转账前后检查余额，使用实际到账金额
Rebase代币代币余额会在无转账的情况下变动不缓存外部余额，始终读取实时余额
无布尔返回值部分代币（如USDT）转账操作不返回布尔值使用
SafeERC20.safeTransfer
ERC777钩子转账钩子可能触发重入所有接收代币的函数使用
ReentrancyGuard
零金额转账
transferFrom(A, B, 0)
可用于地址投毒		拒绝零金额转账
授权竞争将授权额度从N改为M时，攻击者可花费N+M使用
safeIncreaseAllowance
/
safeDecreaseAllowance

9. MEV / Front-Running

9. MEV / 抢跑（MEV / Front-Running）

TypeDescriptionDefense
Sandwich attackAttacker front-runs buy + back-runs sell around victimSlippage protection + deadline parameter
ERC4626 inflationFirst depositor donates to inflate share price, rounding out later depositorsMinimum first deposit or virtual shares (ERC4626 with offset)
Approval front-runAttacker spends old allowance before new allowance tx confirmsUse 
increaseAllowance
not 
approve
Unrestricted withdrawalAttacker monitors mempool for withdraw tx, front-runs with ownRequire commit-reveal or auth binding
类型描述防护方案
三明治攻击攻击者在用户交易前后分别发起买/卖交易获利滑点保护+ deadline参数
ERC4626通胀攻击首个存款人捐赠资金抬高份额价格，后续存款人被舍入损失最低首次存款要求或虚拟份额（带偏移的ERC4626）
授权抢跑攻击者在新授权交易确认前花费旧授权额度使用
increaseAllowance
而非
approve
无限制提款攻击者监控mempool中的提款交易，抢跑发起自己的提款要求提交-揭示机制或权限绑定

10. Storage & Low-Level

10. 存储与底层操作（Storage & Low-Level）

IssueDescription
Storage pointer
Foo storage foo = arr[0]; foo = arr[1];
— does NOT update arr[0]
Nested delete
delete structWithMapping
— inner mapping data persists
Private variablesAll contract storage is publicly readable via 
eth_getStorageAt
Unsafe delegatecallDelegatecall to untrusted contract can 
selfdestruct
the caller
Proxy storage collisionUpgrade changes parent order → variables overwrite each other (use storage gaps)
msg.value in loopmsg.value doesn't decrease in loop — enables double-spend
问题描述
存储指针错误
Foo storage foo = arr[0]; foo = arr[1];
— 不会更新arr[0]
嵌套删除问题
delete structWithMapping
— 内部的mapping数据会残留
私有变量可见性所有合约存储都可以通过
eth_getStorageAt
公开读取
不安全delegatecall对不可信合约发起delegatecall可能导致调用者被
selfdestruct
代理存储冲突升级修改父合约顺序→变量互相覆盖（使用存储缺口解决）
循环中的msg.value循环中msg.value不会递减，可导致双花

11. Contract Detection Bypass

11. 合约检测绕过（Contract Detection Bypass）

MethodHow it works
Constructor callAttack from constructor — 
extcodesize == 0
during deployment
CREATE2 pre-computePre-calculate contract address, use as EOA before deploying
方法原理
构造函数调用从构造函数发起攻击 — 部署过程中
extcodesize == 0
CREATE2预计算预计算合约地址，部署前当作EOA使用

12. Proxy & Upgrade Vulnerabilities

12. 代理与升级漏洞（Proxy & Upgrade Vulnerabilities）

Source: EVMbench Paper §4.2, Appendix H / Code4rena 2024-07-basin H-01
CheckDetail
_authorizeUpgrade
access control		UUPS 
_authorizeUpgrade
must have 
onlyOwner
modifier?
Permissionless factory/registryCan attacker use permissionless factory (e.g. Aquifer 
boreWell
) to satisfy upgrade checks?
upgradeTo
modifier		Overridden 
upgradeTo
/
upgradeToAndCall
retains 
onlyProxy
modifier?
Initializer protection
initializer
modifier prevents re-initialization? Implementation calls 
_disableInitializers()
?
Storage layout compatibilityUpgrade-safe storage layout (storage gaps or ERC-7201 namespace)?
Case: Code4rena 2024-07-basin H-01 (via EVMbench Paper Fig.12, p.19) — 
_authorizeUpgrade
only checked delegatecall and Aquifer registration but lacked 
onlyOwner
, allowing anyone to upgrade a Well proxy to a malicious implementation and drain funds. Oracle patch: add a single 
onlyOwner
modifier.
来源：EVMbench Paper §4.2, Appendix H / Code4rena 2024-07-basin H-01
检查项详情
_authorizeUpgrade
访问控制		UUPS的
_authorizeUpgrade
必须有
onlyOwner
修饰符？
无许可工厂/注册表攻击者能否使用无许可工厂（如Aquifer 
boreWell
）绕过升级校验？
upgradeTo
修饰符		重写的
upgradeTo
/
upgradeToAndCall
保留了
onlyProxy
修饰符？
初始化器防护
initializer
修饰符可防止重复初始化？实现合约调用了
_disableInitializers()
？
存储布局兼容性存储布局支持升级（使用存储缺口或ERC-7201命名空间）？
案例：Code4rena 2024-07-basin H-01（来自EVMbench Paper Fig.12, p.19）— 
_authorizeUpgrade
仅检查了delegatecall和Aquifer注册，缺少
onlyOwner
校验，任何人都可以将Well代理升级为恶意实现并耗尽资金。修复方案：添加一个
onlyOwner
修饰符即可。

13. Trust Boundary & Protocol Composability

13. 信任边界与协议可组合性（Trust Boundary & Protocol Composability）

Source: EVMbench Paper §4.2.1, Fig.6 / Code4rena 2024-04-noya H-08, 2024-07-benddao
CheckDetail
Cross-vault trust isolationRegistry/Router relay calls verify vault-level authorization?
Trusted sender abuseFunctions like 
sendTokensToTrustedAddress
verify source vault, not just router identity?
Flash loan + routing comboCan attacker use flash loan callback to make router impersonate arbitrary vault?
Collateral ownership verificationLiquidation/staking operations verify actual NFT/collateral owner?
Cross-contract state dependencyMulti-contract interactions free from intermediate state dependencies?
Cases:
来源：EVMbench Paper §4.2.1, Fig.6 / Code4rena 2024-04-noya H-08, 2024-07-benddao
检查项详情
跨金库信任隔离注册表/路由的中继调用校验了金库级别的授权？
可信发送方滥用
sendTokensToTrustedAddress
这类函数校验了源金库，而非仅校验路由身份？
闪电贷+路由组合攻击攻击者能否使用闪电贷回调让路由伪装成任意金库？
抵押品所有权校验清算/质押操作校验了NFT/抵押品的实际所有者？
跨合约状态依赖多合约交互不存在中间状态依赖？
案例:

14. State Ordering & Counter Manipulation

14. 状态顺序与计数器操作（State Ordering & Counter Manipulation）

Source: EVMbench Paper Appendix H.1, Fig.19-21 / Code4rena 2024-08-phi H-06
CheckDetail
Counter/ID increment order
credIdCounter++
or similar ID increments happen before external calls?
Auto-buy in create
create()
functions with auto 
buy()
calls execute only after ID/state fully initialized?
Refund timingETH refund (excess) happens after all state updates complete?
Bonding curve metadata overwriteCan attacker reenter to modify bonding curve/pricing params — buy cheap, switch to expensive curve, sell high?
Case: Code4rena 2024-08-phi H-06 (via EVMbench Paper Appendix H.1, p.25-28) — 
_createCredInternal
called 
buyShareCred
before incrementing 
credIdCounter
; 
_handleTrade
refunded excess ETH before updating 
lastTradeTimestamp
. Attacker reentered to accumulate shares on cheap curve, overwrote metadata to expensive curve, sold to drain all contract ETH. Fix: add 
nonReentrant
to 
buyShareCred
/
sellShareCred
.
来源：EVMbench Paper Appendix H.1, Fig.19-21 / Code4rena 2024-08-phi H-06
检查项详情
计数器/ID递增顺序
credIdCounter++
或类似的ID递增操作在外部调用前完成？
创建时自动购买自带
buy()
调用的
create()
函数仅在ID/状态完全初始化后执行？
退款时机ETH超额退款在所有状态更新完成后执行？
bonding curve元数据覆盖攻击者能否重入修改bonding curve/定价参数 — 低价买入，切换为高价曲线后高价卖出？
案例：Code4rena 2024-08-phi H-06（来自EVMbench Paper Appendix H.1, p.25-28）— 
_createCredInternal
在递增
credIdCounter
前调用了
buyShareCred
；
_handleTrade
在更新
lastTradeTimestamp
前退还超额ETH。攻击者重入在低价曲线累积份额，将元数据修改为高价曲线后卖出，耗尽合约所有ETH。修复方案：给
buyShareCred
/
sellShareCred
添加
nonReentrant
修饰符。

Infrastructure-Level Vulnerabilities

基础设施层面漏洞

15. Frontend / UI Injection

15. 前端/UI注入

Attackers inject malicious code into the dApp frontend or signing interface.
Defense: Verify transaction calldata matches expected function selector and parameters before signing. Use hardware wallet with on-device transaction preview. Audit all frontend dependencies regularly.
Case: Bybit (Feb 2025, $1.4B) — malicious JavaScript injected into Safe{Wallet} UI, tampered with transaction data during signing.
攻击者向dApp前端或签名界面注入恶意代码。
防护方案：签名前校验交易calldata与预期的函数选择器、参数匹配。使用带设备内交易预览的硬件钱包。定期审计所有前端依赖。
案例：Bybit (2025年2月, 14亿美元) — Safe{Wallet} UI被注入恶意JavaScript，签名过程中交易数据被篡改。

16. Private Key & Social Engineering

16. 私钥与社会工程学攻击

Compromised keys remain the #1 loss source in 2025-2026.
Defense: Store keys in HSM or hardware wallet. Use multisig (≥ 3/5) for all treasury and admin operations. Never share seed phrases with any "support" contact. Conduct regular social engineering awareness training.
Case: Step Finance (Jan 2026, $30M) — treasury wallet private keys compromised via device breach.
密钥泄露仍是2025-2026年资金损失的首要原因。
防护方案：将密钥存储在HSM或硬件钱包中。所有国库和管理员操作使用多签（≥3/5）。永远不要向任何“支持”人员泄露助记词。定期开展社会工程学意识培训。
案例：Step Finance (2026年1月, 3000万美元) — 国库钱包私钥因设备 breach 泄露。

17. Cross-Chain Bridge

17. 跨链桥

CheckDetail
Inherited codeAudit all bridge logic inherited from third-party frameworks
Message verificationCross-chain messages validated with proper signatures and replay protection?
Liquidity isolationBridge funds separated from protocol treasury?
Case: SagaEVM (Jan 2026, $7M) — inherited vulnerable EVM precompile bridge logic from Ethermint.
检查项详情
继承代码审计所有从第三方框架继承的跨链桥逻辑？
消息校验跨链消息通过正确的签名和重放防护校验？
流动性隔离跨链桥资金与协议国库隔离？
案例：SagaEVM (2026年1月, 700万美元) — 从Ethermint继承了存在漏洞的EVM预编译跨链桥逻辑。

18. Legacy / Deprecated Contracts

18. 旧版/废弃合约

Old contracts with known bugs remain callable on-chain forever.
Defense: Permanently 
pause
or migrate funds from deprecated contracts. Monitor old contract addresses for unexpected activity. Remove mint/admin functions before deprecation.
Case: Truebit (Jan 2026, $26.4M) — Solidity 0.6.10 contract lacked overflow protection, attacker minted tokens at near-zero cost.
存在已知漏洞的旧合约会永久保留在链上可被调用。
防护方案：永久
pause
废弃合约或迁移其中的资金。监控旧合约地址的异常活动。废弃前移除mint/管理员功能。
案例：Truebit (2026年1月, 2640万美元) — Solidity 0.6.10版本的合约缺少溢出防护，攻击者以接近零的成本 mint 代币。

Automated Analysis with Slither MCP (if available)

使用Slither MCP自动分析（若可用）

When 
slither
MCP is configured, run automated analysis BEFORE the manual checklist below:
配置了
slither
MCP时，在手动检查之前先运行自动分析：

Recommended Audit Flow

推荐审计流程

Step 1: slither MCP automated scan
        → get_detector_results(path, impact="High")
        → get_detector_results(path, impact="Medium")
Step 2: Review Slither findings — triage true positives vs false positives
Step 3: Manual checklist below — catch what Slither misses (business logic, economic attacks)
Step 4: Cross-reference — Slither + manual findings combined into final report
Step 1: slither MCP automated scan
        → get_detector_results(path, impact="High")
        → get_detector_results(path, impact="Medium")
Step 2: Review Slither findings — triage true positives vs false positives
Step 3: Manual checklist below — catch what Slither misses (business logic, economic attacks)
Step 4: Cross-reference — Slither + manual findings combined into final report

Slither MCP Tools

Slither MCP工具

ToolUsageComplements
get_contract_metadata
Extract functions, inheritance, flagsManual access control review
get_function_source
Get exact source code with line numbersFaster than grep for locating code
find_implementations
Find all implementations of a function signatureCross-contract reentrancy analysis
get_detector_results
Run 90+ security detectors, filter by impact/confidenceAutomated version of manual checklist
get_detector_metadata
List available detectors with descriptionsUnderstanding what's being checked
工具用途补充场景
get_contract_metadata
提取函数、继承关系、标记手动访问控制审查
get_function_source
获取带行号的精确源代码比grep更快定位代码
find_implementations
查找某个函数签名的所有实现跨合约重入分析
get_detector_results
运行90+安全检测器，按影响/置信度过滤手动检查清单的自动化版本
get_detector_metadata
列出可用检测器及描述理解检查范围

What Slither Catches vs What It Misses

Slither可检测项与需手动检查项

Slither Catches WellManual Review Still Needed
Reentrancy patternsBusiness logic flaws
Unprotected functionsEconomic attack vectors (flash loan combos)
Unused state variablesCross-protocol composability risks
Shadowing issuesOracle manipulation scenarios
Incorrect ERC20 interfaceTrust boundary architecture issues
Dead codeMEV/front-running specific to business logic
Key Principle: Slither provides ground truth via static analysis — reduces false negatives on known vulnerability patterns. But it cannot reason about protocol-level economic attacks — that's where the manual checklist below is essential.
Graceful degradation: If slither MCP is not configured, skip this section and proceed directly to the manual checklist. All checklist items remain valid and self-contained.
Slither擅长检测仍需手动审查
重入模式业务逻辑缺陷
未受保护的函数经济攻击向量（闪电贷组合攻击）
未使用的状态变量跨协议可组合性风险
变量遮蔽问题预言机操纵场景
错误的ERC20接口信任边界架构问题
死代码与业务逻辑相关的MEV/抢跑问题
核心原则：Slither通过静态分析提供基础事实，减少已知漏洞模式的漏报。但它无法推理协议层面的经济攻击——这就是手动检查清单的核心价值所在。
降级方案：如果未配置slither MCP，跳过本节直接执行手动检查清单即可，所有检查项都是自包含的有效规则。

Audit Execution Checklist

审计执行清单

When conducting a security audit, check each item:
Reentrancy:
  • All functions with external calls use 
    nonReentrant
  • CEI pattern followed — no state reads after external calls
  • View functions not used as oracle during state transitions
Access Control:
  • Every state-changing function has explicit access modifier
  • Modifiers actually revert (not silently pass)
  • Admin privileges are minimal and documented
Input & Logic:
  • No unvalidated arbitrary 
    call
    / 
    delegatecall
  • No 
    tx.origin
    for authentication
  • Array lengths validated for paired inputs
  • No division-before-multiplication precision loss
Token Handling:
  • All ERC20 ops use 
    SafeERC20
  • Fee-on-transfer tokens handled (balance diff check)
  • Rebase token balances not cached
  • Zero-amount transfers rejected
Price & Oracle:
  • No raw spot price usage
  • Stale price check (
    updatedAt
    / 
    answeredInRound
    )
  • Minimum liquidity threshold enforced
  • Price deviation circuit breaker
Signature & Crypto:
  • ecrecover
    result checked against 
    address(0)
  • Signed data includes 
    chainId
    , 
    nonce
    , 
    msg.sender
    , 
    deadline
  • Using OZ 
    ECDSA
    (low-s enforced)
  • MerkleProof leaves bound to 
    msg.sender
Flash Loan Defense:
  • Governance: snapshot voting + holding period + timelock
  • Price: TWAP or multi-oracle, not single-block spot
  • Vault: minimum first deposit or virtual shares (ERC4626)
Proxy & Upgrade (EVMbench):
  • UUPS 
    _authorizeUpgrade
    has 
    onlyOwner
    — [EVMbench/basin H-01]
  • upgradeTo
    /
    upgradeToAndCall
    retains 
    onlyProxy
    — [EVMbench/basin H-01]
  • Implementation constructor calls 
    _disableInitializers()
    — [EVMbench/basin H-01]
  • Storage layout upgrade-compatible (storage gaps or ERC-7201) — [EVMbench/basin H-01]
Trust Boundary & Composability (EVMbench):
  • Router/Registry relay calls verify source vault/contract authorization — [EVMbench/noya H-08]
  • Liquidation operations verify actual collateral ownership — [EVMbench/benddao]
  • Flash loan callback paths cannot be abused to penetrate trust boundaries — [EVMbench/noya H-08]
  • No intermediate state dependencies in multi-contract interactions — [EVMbench/noya H-08]
State Ordering (EVMbench):
  • Counter/ID increments complete before external calls — [EVMbench/phi H-06]
  • ETH refunds execute after all state updates — [EVMbench/phi H-06]
  • Auto-operations in create functions (auto-buy etc.) execute after full initialization — [EVMbench/phi H-06]
Infrastructure:
  • Third-party dependencies audited (bridge code, inherited contracts)
  • No deprecated contracts still callable with admin/mint functions
  • Multisig on all treasury and admin wallets
  • Frontend transaction verification (calldata matches expected)
开展安全审计时，检查每个条目：
重入漏洞:
  • 所有带外部调用的函数都使用
    nonReentrant
  • 遵循CEI模式 — 外部调用后不再读取状态
  • 状态转换过程中不会把视图函数用作预言机
访问控制:
  • 所有修改状态的函数都有明确的访问修饰符
  • 修饰符校验失败时会正确回滚（不会静默通过）
  • 管理员权限最小化且有文档记录
输入与逻辑:
  • 不存在未校验的任意
    call
    /
    delegatecall
  • 不使用
    tx.origin
    做身份校验
  • 成对输入的数组长度已校验
  • 不存在先除后乘导致的精度损失
代币处理:
  • 所有ERC20操作使用
    SafeERC20
  • 正确处理转账扣费代币（校验余额差值）
  • 不缓存Rebase代币余额
  • 拒绝零金额转账
价格与预言机:
  • 不直接使用原始现货价格
  • 价格过时校验（
    updatedAt
    /
    answeredInRound
    ）
  • 已强制执行最低流动性阈值
  • 已配置价格偏差断路器
签名与加密:
  • 校验
    ecrecover
    返回结果不为
    address(0)
  • 签名数据包含
    chainId
    、
    nonce
    、
    msg.sender
    、
    deadline
  • 使用OZ的
    ECDSA
    （强制低s值）
  • MerkleProof叶子节点与
    msg.sender
    绑定
闪电贷防护:
  • 治理：快照投票+持有周期+时间锁
  • 价格：使用TWAP或多预言机，不使用单块现货价格
  • 金库：最低首次存款要求或虚拟份额（ERC4626）
代理与升级（EVMbench）:
  • UUPS的
    _authorizeUpgrade
    有
    onlyOwner
    修饰符 — [EVMbench/basin H-01]
  • upgradeTo
    /
    upgradeToAndCall
    保留了
    onlyProxy
    修饰符 — [EVMbench/basin H-01]
  • 实现合约构造函数调用了
    _disableInitializers()
    — [EVMbench/basin H-01]
  • 存储布局支持升级（存储缺口或ERC-7201） — [EVMbench/basin H-01]
信任边界与可组合性（EVMbench）:
  • 路由/注册表中继调用校验了源金库/合约授权 — [EVMbench/noya H-08]
  • 清算操作校验了抵押品实际所有权 — [EVMbench/benddao]
  • 闪电贷回调路径无法被滥用突破信任边界 — [EVMbench/noya H-08]
  • 多合约交互不存在中间状态依赖 — [EVMbench/noya H-08]
状态顺序（EVMbench）:
  • 计数器/ID递增在外部调用前完成 — [EVMbench/phi H-06]
  • ETH退款在所有状态更新完成后执行 — [EVMbench/phi H-06]
  • 创建函数中的自动操作（自动购买等）在完全初始化后执行 — [EVMbench/phi H-06]
基础设施:
  • 第三方依赖已审计（跨链桥代码、继承合约）
  • 废弃合约已关闭admin/mint功能，不可再调用
  • 所有国库和管理员钱包使用多签
  • 前端支持交易校验（calldata与预期匹配）

AI Agent Audit Methodology

AI Agent审计方法论

Source: EVMbench (OpenAI/Paradigm, Feb 2026) — evaluated AI agents on 120 high-severity vulnerabilities from 40 Code4rena audit repositories across Detect/Patch/Exploit modes.
来源：EVMbench (OpenAI/Paradigm, 2026年2月) — 在检测/修复/利用模式下评估AI Agent处理40个Code4rena审计库的120个高危漏洞的能力。

Audit Strategy

审计策略

  1. Coverage over depth: scan ALL in-scope files; do not stop after finding the first vulnerability [EVMbench §5, p.10]
  2. Three-phase audit: Detect (identify vulnerabilities) -> Patch (write fix) -> Exploit (build PoC) [EVMbench §3.2, p.5]
  3. Incremental output: write findings continuously during audit to preserve progress [EVMbench Appendix G, Fig.18, p.24]
  4. Systematic category scan: check by vulnerability class (reentrancy, access control, numerical, oracle...) rather than intuition [EVMbench §3.1, p.4]
  5. Verify fixes: after patching, confirm original tests still pass AND exploit is no longer viable [EVMbench §3.2.2, p.5]
  1. 覆盖优先于深度：扫描所有范围内的文件，不要找到第一个漏洞就停止 [EVMbench §5, p.10]
  2. 三阶段审计：检测（识别漏洞）→ 修复（编写修复代码）→ 利用（构建PoC）[EVMbench §3.2, p.5]
  3. 增量输出：审计过程中持续记录发现，保留进度 [EVMbench Appendix G, Fig.18, p.24]
  4. 系统分类扫描：按漏洞类别（重入、访问控制、数值、预言机...）检查，而非凭直觉 [EVMbench §3.1, p.4]
  5. 修复验证：修复后确认原有测试仍可通过，且漏洞无法再被利用 [EVMbench §3.2.2, p.5]

High-Frequency Vulnerability Patterns (Code4rena Data)

高频漏洞模式（Code4rena数据）

Source: EVMbench Table 4 (p.17) — 40 audit repositories
  • Missing access control (upgradeability, liquidation, admin functions) — basin H-01, munchables, benddao
  • Reentrancy + state ordering errors (refund before state update) — phi H-06, noya H-08
  • Flash loan trust boundary penetration (exploiting router/registry trust propagation) — noya H-08
  • Signature replay / front-running (checkpoint bypass, session signature replay) — sequence H-01, H-02
  • Numerical precision / rounding (bonding curve, micro-withdrawals) — abracadabra H-02, size H-02
来源：EVMbench表4（p.17）— 40个审计库
  • 缺少访问控制（升级、清算、管理员函数）— basin H-01、munchables、benddao
  • 重入+状态顺序错误（状态更新前退款）— phi H-06、noya H-08
  • 闪电贷突破信任边界（利用路由/注册表信任传递）— noya H-08
  • 签名重放/抢跑（检查点绕过、会话签名重放）— sequence H-01、H-02
  • 数值精度/舍入误差（bonding curve、小额提款）— abracadabra H-02、size H-02

Key Findings

关键结论

Source: EVMbench Paper §4.1 (p.7), Fig.7 (p.10), Fig.10 (p.18), Fig.11 (p.19)
  • With mechanism hints, Patch success rate jumps from ~40% to ~94% [Fig.7] — agents know how to fix but struggle to find vulnerabilities
  • Most vulnerabilities require ≤5 lines of code to fix [Fig.10, p.18]
  • Most exploits require only 1-3 transactions [Fig.11, p.19]
  • Agents whose finding count is closest to actual vulnerability count score highest (quality > quantity) [Fig.5, p.8]
来源：EVMbench Paper §4.1 (p.7), Fig.7 (p.10), Fig.10 (p.18), Fig.11 (p.19)
  • 给出机制提示后，修复成功率从40%跃升至94% [Fig.7] — Agent知道如何修复，但难以发现漏洞
  • 大多数漏洞修复需要≤5行代码 [Fig.10, p.18]
  • 大多数漏洞利用仅需要1-3笔交易 [Fig.11, p.19]
  • 发现漏洞数量最接近实际数量的Agent得分最高（质量>数量）[Fig.5, p.8]

2021-2026 Incident Quick Reference

2021-2026安全事件速查表

DateProjectLossAttack TypeRoot CauseSource
Oct 2021Cream Finance$130MFlash loan + oracleyUSD vault price manipulation via supply reductionrekt.news
Feb 2025Bybit$1.4BUI injection / supply chainSafe{Wallet} JS tampered via compromised dev machineNCC Group
Mar 2025Abracadabra$13MLogic flawState tracking error in cauldron liquidationHalborn
Jul 2025GMX v1$42MReentrancyGLP pool cross-contract reentrancy on ArbitrumHalborn
Sep 2025Bunni$8.4MFlash loan + roundingRounding direction error in withdraw, 44 micro-withdrawalsThe Block
Oct 2025Abracadabra #2$1.8MLogic flawcook() validation flag reset, uncollateralized MIM borrowHalborn
Jan 2026Step Finance$30MKey compromiseTreasury wallet private keys stolen via device breachHalborn
Jan 2026Truebit$26.4MLegacy contractSolidity 0.6.10 integer overflow in mint pricingCoinDesk
Jan 2026SagaEVM$7MSupply chain / bridgeInherited Ethermint precompile bridge vulnerabilityThe Block
日期项目损失攻击类型根本原因来源
2021年10月Cream Finance1.3亿美元闪电贷+预言机攻击通过减少供给操纵yUSD金库价格rekt.news
2025年2月Bybit14亿美元UI注入/供应链攻击开发机器被入侵导致Safe{Wallet} JS被篡改NCC Group
2025年3月Abracadabra1300万美元逻辑漏洞cauldron清算的状态跟踪错误Halborn
2025年7月GMX v14200万美元重入漏洞Arbitrum链上GLP池跨合约重入Halborn
2025年9月Bunni840万美元闪电贷+舍入误差提款的舍入方向错误，44次小额提款获利The Block
2025年10月Abracadabra #2180万美元逻辑漏洞cook()校验标志被重置，无抵押借贷MIMHalborn
2026年1月Step Finance3000万美元密钥泄露国库钱包私钥因设备 breach 被盗Halborn
2026年1月Truebit2640万美元旧合约漏洞Solidity 0.6.10版本mint定价存在整数溢出CoinDesk
2026年1月SagaEVM700万美元供应链/跨链桥漏洞继承了Ethermint预编译跨链桥漏洞The Block