Smart contract access control vulnerabilities
Access control flaws let the wrong account call a privileged function: minting, withdrawing, pausing, upgrading or changing fees. They come from missing modifiers, initialisers left callable, roles granted too widely, and checks that trust tx.origin or an address that can be spoofed. They are simple flaws with total consequences, and they are caught by reading the code.
Common causes
- Missing modifiers on functions that should be restricted.
- Callable initialisers in upgradeable contracts, letting anyone set the owner.
- Over-broad roles, where one role can do far more than its holder needs.
- tx.origin checks, which a malicious contract can satisfy by tricking the owner into calling it.
- Unchecked callers on callbacks and cross-chain message receivers.
- Leftover test functions and backdoors that were never meant to ship.
- Renounced ownership that leaves necessary functions uncallable.
Prevention
- List every privileged function, who should call it, and why.
- Use established role-based access control rather than custom checks.
- Protect initialisers and lock implementation contracts.
- Put powerful roles behind timelocks and multisigs.
- Test that every restricted function rejects unauthorised callers.
Frequently asked questions
Why do scanners miss access control bugs?
Scanners can flag a function with no modifier, but they cannot know which functions should be restricted or who should hold each role. That needs someone who understands what the protocol is meant to do.
Is a multisig enough for admin functions?
A multisig spreads the risk across several keys, which helps. Add a timelock for anything that can move funds or change logic, and limit what each role can do.
Published Updated