# User can bypass MAX_EXPIRATION when extend expiration

Initia name service extend_expiration validated duration delta instead of absolute expiration, letting users double MAX_EXPIRATION and register domains far beyond the intended cap.

- Payout: Contest reward
- Severity: high
- Program: Initia
- Credited: laksmana
- Disclosed: 2025-04-10
- Write-up quality: 6/10
- Original: https://code4rena.com/reports/2025-01-initia-move#h-03
- Library page: https://bugbountylibrary.com/r/c4%3A2025-01-initia-move%3AH-03
- Tags: domain:web3 impact:integrity kind:contest platform:code4rena sev:high tech:solidity technique:source-review vuln:business-logic

**Target:** Move usernames/name-service module extend_expiration
**Root cause:** Validation checks new_expiration_date - expiration_date <= MAX_EXPIRATION, which is always true when new_expiration_date = expiration_date + duration, so the absolute expiration is never bounded.
**Steps:**
1. Register a domain with duration = MAX_EXPIRATION so expiration_date = timestamp + MAX_EXPIRATION.
2. Call `extend_expiration(user, "abcd", MAX_EXPIRATION)`.
3. new_expiration_date = expiration_date + duration; the assert `new_expiration_date - expiration_date <= MAX_EXPIRATION` passes since it equals duration.
4. update_expiration_date stores expiration >= MAX_EXPIRATION * 2, bypassing the cap.
**How found:** Code reading of extend_expiration: noticed the assert subtracts expiration_date from new_expiration_date, making the check tautological relative to duration rather than bounding the absolute expiration.
**Exploitation:** Any user registers a name at the max duration then calls extend_expiration with MAX_EXPIRATION to push expiration to roughly 2x the intended maximum, holding the name far longer than allowed.
**Insight:** When validating a cap on an absolute value (expiration, balance, timestamp), check the resulting absolute value against the bound, not a delta between old and new — delta checks are trivially satisfied by construction.