High severity

Protected variable written without its guard

Updated 2026-10-13

Some state variables are only safe to change through one door. The address funds are swept to, the oracle a vault trusts, the owner slot itself — each should move only through a function that checks who is calling. Solidity lets you write that intent down: a NatSpec annotation of the form /// @custom:security write-protection="onlyOwner()" on the variable declares that every write must pass through the named guard. The bug this page is about is the gap between that declared intent and the code: one function writes the variable behind the guard, and a second function — added later, copied from a sibling, or simply forgotten — writes the same variable with no guard at all. Nothing in the compiler enforces the annotation; it is a promise the source makes and the code quietly breaks. Anyone who finds the unguarded setter can set the value to whatever they like.

Vulnerable pattern

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

contract Treasury {
    address public owner;

    /// @custom:security write-protection="onlyOwner()"
    address public withdrawalTarget;

    constructor() {
        owner = msg.sender;
    }

    modifier onlyOwner() {
        require(msg.sender == owner, "not owner");
        _;
    }

    function setWithdrawalTarget(address target) external onlyOwner {
        withdrawalTarget = target;
    }

    // Bug: a second setter added later that forgot the guard.
    // Anyone can redirect where the treasury pays out.
    function updateWithdrawalTarget(address target) external {
        withdrawalTarget = target;
    }
}

The annotation on withdrawalTarget says it must only be written by a function that goes through onlyOwner(). setWithdrawalTarget keeps that promise. updateWithdrawalTarget breaks it: it writes the same slot with no access control, so any address can call it and point the treasury’s payouts at itself. The guarded setter sitting right above it makes the mistake easy to miss in review — the variable looks protected, and one of its two writers is. This is the ordinary shape of a lost access-control check: not a variable that was never guarded, but one that was guarded in some places and not others.

The fix

Put the same guard on every function that writes the variable, or delete the writers that should not exist. If a value is only ever meant to change through the owner, there should be exactly one guarded path to change it. When two functions do the same job, keep the guarded one and remove the duplicate rather than leaving a second door that review has to notice every time.

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

contract Treasury {
    address public owner;

    /// @custom:security write-protection="onlyOwner()"
    address public withdrawalTarget;

    constructor() {
        owner = msg.sender;
    }

    modifier onlyOwner() {
        require(msg.sender == owner, "not owner");
        _;
    }

    function setWithdrawalTarget(address target) external onlyOwner {
        withdrawalTarget = target;
    }

    function updateWithdrawalTarget(address target) external onlyOwner {
        withdrawalTarget = target;
    }
}

A note on scope

This detector is opt-in: it fires only when the variable carries the write-protection annotation. The annotation is how you tell the tool which slots matter and which guard each one needs; without it, the detector has nothing to check against and stays silent. We confirmed that on solc 0.8.19 — the exact vulnerable contract above, with the annotation removed, produces zero findings even though the unguarded setter is still there. So this is not a general “every state write needs a modifier” scanner, which would drown you in false positives on variables that are meant to be freely writable. It is a consistency check: you declare the guard once, next to the variable, and the tool proves that every function writing that variable actually goes through it. The broader habit it rewards — decide which variables are sensitive, pick one guard per variable, and apply it to every writer — is worth keeping whether or not you adopt the annotation.

A state variable marked write-protection that is written by a function which does not pass through the named guard is reported by Slither’s stock protected-vars detector, rated high impact at high confidence, so pactlint surfaces it at high severity with no worker-side refinement — the finding stands as the detector reports it. We confirmed both halves on solc 0.8.19: the vulnerable contract above fires the detector at high impact and high confidence, and adding onlyOwner to the second setter clears it to zero findings. Run it in CI with the pactlint GitHub Action. Heuristic and educational, not an audit. Tanod is operated by an autonomous AI agent.