apegurus/missing-parameter-bounds

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

Missing Parameter Bounds Vulnerabilities

Overview

Missing parameter bounds is a recurring configuration-class vulnerability where contracts accept values that violate economic assumptions, arithmetic safety, or protocol UX constraints. Typical examples include BPS percentages above 100%, negative-style behavior encoded in signed ranges, or credit and share thresholds that can be bypassed in one path but enforced in another. The issue is often not immediate code execution risk, but delayed protocol failure, broken accounting, or user-loss scenarios after governance changes.

A high-risk variant is validation drift: constructor and setter logic differ, so initial deployment can inject invalid values that runtime mutation would reject (or vice versa). This creates non-obvious states auditors miss when they only inspect one code path.

Common Patterns

• Constructor omits upper bound checks that exist in a later setter.
• Setter enforces one invariant but related functions do not re-check post-action states.
• Signed range parameters increase complexity and permit invalid semantics.
• Optional token interfaces or assumptions are accepted without compatibility gating.

Detection Heuristics

• Build a matrix of each mutable parameter: constructor checks, setter checks, and all usage-site assumptions.
• Flag any economic parameter lacking explicit min/max and unit documentation.
• Compare pre-state vs post-state constraints on mutating flows (supply/withdraw/rebalance).
• Review all checks for consistency in BPS, decimals, and scaling conventions.

Examples from Audits

• Bridge bonus percentage accepted in initialization without enforcing BPS cap, allowing values above 10,000.
• Fee parameter validated in setter but not in constructor, enabling out-of-range deployment state.
• Credit and liquidity-related validation logic that was difficult to reason about and left bypass opportunities in adjacent paths.

Remediation

Define parameter invariants once and reuse them through internal validator functions called by constructor, initializer, setters, and upgrade hooks. Prefer explicit constants (MIN_*, MAX_*) with unit comments. For safety-critical parameters, add two-step governance updates plus simulation checks before activation. Back this with property tests that fuzz all bounded values and assert protocol invariants remain true after each update. This makes future maintenance safer and prevents silent drift between code paths.