apegurus/zero-address-misconfiguration

<!-- Source: BailSec audit reports (CC0) -->

Zero Address Misconfiguration Vulnerabilities

Overview

Zero-address handling is an input validation and configuration integrity problem: critical system variables are set to address(0) even though downstream logic assumes a live recipient. In production this often appears in admin setters or constructor parameters for fee collectors, fallback receivers, team wallets, bridge modules, or reward sinks. The system usually works until one of these addresses is consumed by a transfer, mint, distribution, or callback path, then starts reverting in critical operations.

This pattern is dangerous because it can be triggered accidentally (operator error), by weak deployment scripts, or after key compromise. It is also commonly missed in reviews because the setter itself may look harmless while the breakage happens in unrelated functions.

Common Patterns

• Missing require(newAddr != address(0)) in privileged setter functions.
• Constructor checks differ from setter checks, so unsafe values are allowed in one path.
• Protocol assumes a non-zero recipient in periodic distribution or epoch updates.
• Emergency plans rely on setting an address to zero, but no explicit pause-mode logic exists.

Detection Heuristics

• Trace every role-controlled address from write path to first transfer/mint usage.
• Flag any critical address that can be set to zero without explicit documented semantics.
• Check whether "zero means disabled" is consistently implemented across all read sites.
• Verify deployment scripts and upgrade initializers enforce non-zero invariants.

Examples from Audits

• Fee-aggregation routing where a primary aggregator could be set to zero, causing later fee forwarding to fail.
• Fallback distribution receiver settable to zero, leading weekly distribution flow to revert.
• Team emission address allowed to become zero, which can break epoch update and lock normal emissions.

Remediation

Use strict non-zero validation in constructors, initializers, and all mutating setters for critical addresses. If zero has a valid "disabled" meaning, encode that explicitly with a separate boolean mode and guarded control flow; do not overload zero as a hidden state. Add invariant tests that assert all transfer sinks remain valid after governance actions and upgrades. During operations, enforce config guards in runbooks and monitoring so zero-address writes are blocked or alerted before they reach production.