Unchecked External Calls

Why this rank in 2026

Held at #6. The category overlaps significantly with SC08 (reentrancy) - most 2025 reentrancy losses also fit here - but OWASP keeps them separate because the prevention pattern is different: SC06 is about *what the callee does*; SC08 is about *when control returns to the original contract*.

Vulnerable vs secure code

// Vulnerable: state updated AFTER the external call; return value ignored
function withdraw(uint256 amount) external {
    require(balances[msg.sender] >= amount, "insufficient");
    (bool ok, ) = msg.sender.call{value: amount}("");   // attacker can reenter
    // even if ok is false, we proceed:
    balances[msg.sender] -= amount;
}

// Secure: CEI + return value checked + ReentrancyGuard
function withdraw(uint256 amount) external nonReentrant {
    uint256 bal = balances[msg.sender];
    require(bal >= amount, "insufficient");
    balances[msg.sender] = bal - amount;                // effect first
    (bool ok, ) = msg.sender.call{value: amount}("");   // interaction
    require(ok, "transfer failed");
}

Prevention checklist

• Treat every external call as untrusted, including calls to standard tokens.
• Apply Checks-Effects-Interactions: validate → update state → call.
• Prefer pull-based payments over push for arbitrary recipients.
• Always check return values; use SafeERC20 for token interactions.
• Be extremely cautious with low-level calls, callbacks, and delegatecall.
• Validate callee identity and permissions on hook and callback entry points.

Deep dive: related SCH attack pages

Sources & methodology

Every claim on this page traces back to a primary, citable source. Open the originals if you want to verify the numbers or read the underlying methodology.

Quoted OWASP descriptions are used under CC BY-NC-SA 4.0. SCH editorial content (analysis, code, prevention prose, FAQ, AI-vs-human rates) is © Smart Contract Hacking.