Unprotected selfdestruct: One Call That Bricks Your Contract

The bug in one sentence

If any function in your contract calls `selfdestruct(x)` and that function isn't gated by access control, anyone on the network can nuke your contract and send its ETH wherever they want. That's it. That's the whole vulnerability.

It sounds too dumb to ship. It shipped. It froze $300 million.

How `selfdestruct` actually works

The `SELFDESTRUCT` opcode (formerly `SUICIDE`) does three things in a single call:

1. Marks the contract for deletion at the end of the transaction.
2. Transfers the entire ETH balance to a target address — **even if that address is a contract with no receive function**.
3. Clears the contract's bytecode and storage.

That third point is the killer. Any other contract that depends on yours — proxies pointing at it, integrators calling its interface, users with allowances — suddenly talks to an empty address. Calls don't revert. They succeed silently, return zero, and your protocol's invariants quietly evaporate.

Note: [EIP-6049](https://eips.ethereum.org/EIPS/eip-6049) formally deprecated `selfdestruct` in 2023, and post-Cancun (EIP-6780) the opcode only fully destroys a contract if called in the same transaction it was created. But it still forwards the ETH balance unconditionally, which is more than enough to drain a contract and break dependent protocols.

The vulnerable pattern

```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract Wallet {
address public owner;

constructor() {
owner = msg.sender;
}

function initialize(address _owner) external {
owner = _owner; // no access control — anyone can re-initialize
}

function kill() external {
selfdestruct(payable(msg.sender)); // no access control — anyone can nuke
}

receive() external payable {}
}
```

Two bugs, both fatal:

`initialize` has no guard, so anyone can become `owner`.
- `kill` has no guard at all, so even the `owner` check wouldn't have helped.

This is essentially the Parity multisig library contract, simplified.

The fix

```solidity
// SPDX-License-Identifier: MIT
pragma solidity ^0.8.20;

contract Wallet {
address public owner;
bool private initialized;

constructor(address _owner) {
owner = _owner;
initialized = true;
}

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

function initialize(address _owner) external {
require(!initialized, "already initialized");
owner = _owner;
initialized = true;
}

// Better: don't include selfdestruct at all.
// If you must, gate it hard and consider a timelock.
function emergencyShutdown(address payable recipient) external onlyOwner {
selfdestruct(recipient);
}

receive() external payable {}
}
```

Three rules of thumb:

1. **Default to not having `selfdestruct` at all.** Most upgrade and pause patterns don't need it. Use a proxy + pause switch instead.
2. **Initialize in the constructor**, or use OpenZeppelin's `Initializable` with the `initializer` modifier — never leave an init function callable twice.
3. **If you keep `selfdestruct`, require multisig + timelock.** A single key with kill rights is an attractive target.

Real-world carnage: Parity, November 2017

The Parity multisig wallet had a shared library contract that wallet instances delegated into. The library was deployed once, uninitialized. A user named `devops199` called `initWallet` on the library, became its owner, then called `kill`. `selfdestruct` wiped the library bytecode.

Every Parity multisig in existence was a `delegatecall` proxy pointing at that now-empty library. Their `execute` and `transfer` functions called into nothing, succeeded silently, and the wallets were left holding ETH they could never move. **513,774 ETH locked**, worth over $300M at the time, roughly $1.5B+ at today's prices. Still locked. Still unrecoverable.

The lesson isn't "selfdestruct is scary" — it's that **every public function on a library or implementation contract needs the same access-control rigor as a user-facing function**. Uninitialized implementations behind proxies remain one of the top findings in audits I run through [cryptohawking.com/audit](https://www.cryptohawking.com/audit).

Where this still shows up in 2025

Even with EIP-6780 narrowing `selfdestruct`'s destructive power, I keep finding variants of this bug:

**Implementation contracts behind UUPS proxies** with an unprotected `_authorizeUpgrade` or leftover `kill` function. The implementation gets nuked; every proxy bricks.
- **Factory-deployed clones** where the template has a public destructor for "cleanup."
- **Vaults and escrows** with a `sweep` function that calls `selfdestruct(treasury)` and forgets `onlyOwner`.
- **CREATE2 redeploy tricks** — attackers `selfdestruct` a contract, then redeploy different bytecode at the same address. Post-Cancun this is much harder, but legacy contracts deployed before are still vulnerable.

Static analyzers (Slither's `suicidal` detector) catch the obvious cases in seconds. Anything more subtle — an unprotected init that *enables* a guarded destructor — needs a human reading the call graph. That's the kind of finding that comes out of a [manual audit](https://www.cryptohawking.com/audit/manual) rather than a tool run.

Checklist before you deploy

[ ] Grep your codebase for `selfdestruct` and `suicide`. Justify every hit.
- [ ] Every initializer has either a constructor-set flag or OZ's `initializer` modifier.
- [ ] Implementation contracts behind proxies have `_disableInitializers()` in the constructor.
- [ ] No single EOA can call a destructor — multisig + timelock minimum.
- [ ] Slither runs clean on `suicidal` and `uninitialized-state`.
- [ ] Your tests include a "hostile caller tries every external function" fuzz pass.

If you can't tick all six, you're one transaction away from a postmortem nobody wants to write.