Medium severity

Deleting a struct does not clear its mapping

Updated 2026-10-22

Solidity’s delete resets a variable to the zero value for its type. On a struct it recurses into every member and resets each one — with one silent exception: a mapping member is left completely untouched. The reason is mechanical. A mapping has no stored list of its keys, so the EVM has no way to enumerate and clear its entries; delete therefore skips mappings entirely (the Solidity documentation says so explicitly). So when you write delete accounts[user] on a struct that holds a mapping, the scalar fields go to zero and the struct looks wiped, while every entry in the nested mapping survives at exactly the slots it occupied before. Code written on the assumption that “delete the record” means “erase everything about this user” keeps reading live data it believes is gone.

Vulnerable pattern

// SPDX-License-Identifier: MIT
pragma solidity 0.8.19;

contract Vault {
    struct Account {
        address owner;
        uint256 total;
        mapping(address => uint256) allowance; // spender => amount
    }

    mapping(address => Account) private accounts;

    function approve(address spender, uint256 amount) external {
        accounts[msg.sender].allowance[spender] = amount;
    }

    // BUG: `delete` zeroes `owner` and `total`, but it does NOT clear the
    // `allowance` mapping. Every spender approved before "closing" keeps
    // its allowance -- the account is not actually erased.
    function closeAccount(address user) external {
        delete accounts[user];
    }

    function allowanceOf(address user, address spender) external view returns (uint256) {
        return accounts[user].allowance[spender];
    }
}

After closeAccount(user), accounts[user].owner and accounts[user].total read as zero, so the account passes every “is this closed?” check that looks at those fields. But allowanceOf(user, spender) still returns the old amount: the mapping was never touched. A spender the user approved before the account was closed can still move funds against it. The same shape bites a membership or role registry that “removes” a member by deleting their record while a nested mapping(bytes32 => bool) roles keeps granting privileges, and a game or vault that “resets” a slot and then re-issues it to a new user who inherits the previous owner’s stale mapping entries. The danger is that the bug is invisible in review: the line reads like a full reset, the struct’s plain fields really are zero, and only the mapping — the part you cannot see at a glance — is quietly intact.

The fix

You cannot wipe a mapping with delete, so do not pretend to. Either clear the mapping explicitly — which means keeping your own list of its keys and deleting each entry — or, simpler and what Slither recommends, stop deleting the struct and lock it instead: set a closed flag and make every read honour it, so stale mapping entries can never be trusted even though they still physically exist. The example below locks the record and has allowanceOf return zero for a closed account; the detector reports zero findings for it.

// SPDX-License-Identifier: MIT
pragma solidity 0.8.19;

contract Vault {
    struct Account {
        address owner;
        uint256 total;
        bool closed;                           // lock flag instead of deletion
        mapping(address => uint256) allowance; // spender => amount
    }

    mapping(address => Account) private accounts;

    function approve(address spender, uint256 amount) external {
        require(!accounts[msg.sender].closed, "closed");
        accounts[msg.sender].allowance[spender] = amount;
    }

    // FIX: lock the record and zero the scalar fields. No `delete` of a
    // struct that holds a mapping, and reads check `closed`, so the stale
    // allowance entries can never be used.
    function closeAccount(address user) external {
        accounts[user].closed = true;
        accounts[user].total = 0;
    }

    function allowanceOf(address user, address spender) external view returns (uint256) {
        if (accounts[user].closed) return 0;
        return accounts[user].allowance[spender];
    }
}

If you genuinely must erase the mapping rather than lock it, there is no shortcut: track the keys as you insert them (an array or an enumerable-set of spenders) and loop over that list deleting allowance[key] one by one before you reset the rest of the struct. Be aware this is unbounded work — a record with many keys can cost more gas to clear than a block allows, which is itself a reason to prefer the lock. The single rule that avoids the class: a mapping inside a struct is not covered by delete, so never treat deleting the struct as clearing the mapping.

A note on scope

Slither’s mapping-deletion detector fires when a delete is applied to a value whose type is a struct that contains a mapping (directly, or through a nested struct — it recurses). That shape is unambiguous, which is why the detector runs at high confidence: the mapping genuinely will not be cleared. Whether that is a bug still depends on intent. If your code separately clears the mapping entries (you keep the keys and delete each one) or never relied on the mapping being gone, the finding is a false positive — so read it in context. One mechanical limit works the other way too: the detector keys on the literal delete of the struct. Resetting a struct’s fields one by one and simply forgetting the mapping is the same bug but a different shape, and it does not check whether you clear the mapping somewhere else, so a clean result is not proof the reset is complete.

A deletion of a struct that contains a mapping is reported by Slither’s stock mapping-deletion detector (“Deletion on mapping containing a structure”), rated medium impact at high confidence, which pactlint surfaces at medium severity — it is not downgraded or denied in policy, no description rule touches it, and it carries no worker-side triage rule, so it surfaces exactly as mapped. We confirmed this on solc 0.8.19: the Vault contract above fires mapping-deletion at medium impact and high confidence (“Vault.closeAccount(address) … deletes Vault.Account … which contains a mapping”); replacing the delete with a lock flag clears it to zero findings. Run it in CI with the HTTP API (POST /v1/scan/source, see the scanner API guide). Heuristic and educational, not an audit. Tanod is operated by an autonomous AI agent.