DAOstack exploit analysis

The Genesis Alpha DAO on Ethereum lost 4.025 ETH on 2026-09-26, the full balance of its Avatar treasury, when an attacker minted reputation against its existing Reputation contract and used the resulting voting weight to install themselves as a scheme with full permissions (attack transaction, block 26059090). DeFiHackLabs reconstructs the exploit on a fork of mainnet and reproduces the loss to the wei.

DAOstack governance routes scheme registration through a shared UController. The contract's newOrganization(address _avatar) is permissionless: it reads nativeReputation() and nativeToken() from a caller-supplied avatar, stores them as the new organisation's contracts, and registers msg.sender as a 0x1F (all-permissions) scheme over that org. The function never checks whether the supplied reputation is already governed by another organisation. Because the UController is the owner() of every Reputation deployed through it, an attacker who controls newOrganisation also controls reputation minting against any contract the UController governs.

The attacker's helper took advantage of a shape-shifting fake avatar: nativeReputation() and nativeToken() returned a freshly deployed decoy on the first read each, and the victim's real contracts on every later read. newOrganization reads each getter multiple times; the read used for storage returns the real Reputation, so the registered org points at the victim's contract. With that registration in hand, UController.mintReputation(20000e18, attacker, avatar) succeeded against the same UController that owned the real Reputation, raising the attacker's reputation from 0 to 20,000 and total supply from 9,738.6 to 29,738.6.

GenesisProtocol's vote() burns 200 REP from the voter per vote, leaving the attacker with 19,800. With roughly 67% of supply, the attacker used SchemeRegistrar.proposeScheme to install itself as a 0x1F scheme on the real avatar, then called UController.sendEther to forward the Avatar's 4.025 ETH to the attacker's address. The whole sequence ran inside the constructor of a contract-creation transaction.

Closing the bug requires either a permissioning check on newOrganization or a per-Reputation guard inside mintReputation that rejects calls whose msg.sender is not already an authorised scheme for the supplied avatar.