Curriculum·G206 Running a Security Review for a Small Team·about 30 min
The public function that should have been caught
By the end of this lesson you can
- →Explain why every state-changing function needs a deliberate answer to who is allowed to call it
- →Explain how a public, unprotected initialization function let an attacker take about 30 million dollars from Parity multisig wallets
- →Compute what a review of function visibility and access control checks, and why it is within a small team's reach
- →Run the who-can-call-this pass over a contract a team deploys or forks
Graduate · enrolled learners
This lesson opens with Parity multisig wallet, 19 July 2017.
- What happened
- Parity's multisig wallet kept its logic in a shared library contract, and each wallet delegated to it. The library held an initialization function that set the wallet's owners, and it was public with no check that it had not already been called. An attacker called that function directly on three high-value wallets, made themselves the sole owner of each, and then withdrew everything, about 30 million dollars in ether. A volunteer group known as the White Hat Group used the same flaw defensively to drain the remaining vulnerable wallets, roughly 150 million dollars, to safety and later returned it. The function that set ownership was reachable by anyone, on wallets that were already live, and nothing in the code stopped a stranger from calling it. It was a public function that should never have been callable from outside, and its visibility was the whole of the bug.
- The decision point
- The Parity flaw was not subtle math or a novel attack. It was a function that changed who owned the wallet, left callable by anyone, on contracts holding tens of millions. A review with one question, for each function that changes state, who is allowed to call this, would have stopped at the initialization function and asked why a stranger can set the owners of a live wallet. That question is within any small team's reach; it needs no formal verification and no cryptography, only the discipline to enumerate the externally callable functions of a contract you deploy or fork and to demand a deliberate access-control answer for each. The most expensive access-control failures are rarely clever. They are a function that should have been internal or guarded, shipped public, and never asked the one question that would have caught it.
- Recorded loss
- $30,000,000
What you will be able to answer
- →What was the Parity July 2017 flaw?
- →What one review question would have caught it?
- →Why is an access-control review within a small team's reach?
- →What does a fork inherit that a review must re-check?
Orientation and Year One are open: anyone can read them without an account. From Year Two onward the lessons are for enrolled learners, because progress through the later years only means anything if it is tracked against a record.
It is free. We do not sell the list and there is nothing to buy at the end of it.
Sources and review
- https://blog.openzeppelin.com/on-the-parity-wallet-multisig-hack-405a8c12e8f7
- https://rekt.news/parity-multisig-1-rekt/
- https://docs.soliditylang.org/en/latest/contracts.html#function-visibility
Confidence high·Volatility low·Reviewed 2026-09-14·Owner unassigned
Contested
The July 2017 Parity theft is reported at about 30 million dollars, roughly 150,000 ether at the time; the White Hat Group's defensive rescue of the remaining wallets is estimated near 150 million dollars. This July incident is distinct from the November 2017 Parity freeze, which involved a different bug in the same library.
The lesson uses Parity for the function-visibility point; the precise sequence of the three drained wallets and the rescue is documented across post-mortems and some ordering details vary.
