myctrl.tools

SC05—Lack of Input Validation

>Control Description

Lack of input validation occurs when smart contracts process external data — function parameters, calldata, cross-chain messages, or signed payloads — without rigorously enforcing that the data is well-formed, within expected bounds, and authorized for the intended operation. This vulnerability applies across all contract types: DeFi protocols, NFT systems, DAOs, bridges, and composable contracts accepting arbitrary calldata. **Key Focus Areas:** - Numeric parameters: amounts, fees, rates, slippage percentages, and collateral factors requiring safe bounds enforcement - Address validation: zero addresses, contract vs. EOA assumptions, delegated or proxy addresses - Off-chain and signed data: signature validation, expiry checks, nonce replay prevention - Cross-chain payloads: message format verification, chain ID validation, sender verification - Admin/governance inputs: configuration values and upgrade parameters often wrongly treated as implicitly trusted **Exploitation Methods:** - Out-of-bounds values (fees exceeding 100%, zero amounts, maximum uint values) breaking invariants - Malformed addresses or payloads bypassing allowlists or causing unexpected behavior - Replay and ordering attacks when nonce, expiry, or chain ID validation is absent - Composability edge cases when contracts assume caller format or trust relayed data without verification

>Prevention & Mitigation Strategies

  1. 1.Validate all external inputs comprehensively, including function parameters, off-chain-signed data, calldata payloads, and cross-chain messages.
  2. 2.Enforce tight invariants with documented ranges for fees, interest rates, leverage, and collateral factors.
  3. 3.Implement non-zero requirements for key addresses and critical limits.
  4. 4.Use custom errors and explicit checks for clarity and gas efficiency.
  5. 5.Treat admin and governance inputs as untrusted until validated, as misconfiguration poses equal risk to explicit exploits.
  6. 6.Include negative testing (fuzzing, property-based testing) to verify unexpected values are rejected.

>Attack Scenarios

#1Cetus Protocol (May 2025, $223M loss)

The primary root cause involved a flawed overflow check in checked_shlw function. However, the protocol allowed extreme liquidity parameters (e.g., ~2^113) without bounds checks. When combined with arithmetic flaws, unvalidated extreme parameters created dangerous edge cases enabling pool drains.

#2Ionic Money (February 2025, ~$6.9M loss)

Attackers exploited insufficient validation by using social engineering to convince the protocol to list a counterfeit LBTC token. The protocol accepted it as collateral without validating token authenticity on-chain. Attackers minted 250 counterfeit LBTC tokens and borrowed approximately $8.6M.

>References

Ask AI

Configure your API key to use AI features.