Gnosis hack - Incident report

On June 1, 2026 there was an exploit targeting Gnosis Pay users through a vulnerability in several Zodiac modules. Ante vaults were affected because we are using the same Delay and Roles modules Gnosis Pay used (see https://docs.ante.org/technical-stuff for more details).

Total loss across all Ante vaults was about $24 in team test accounts (<0.02% of Assets Under Trust at the time of exploit). Here's what happened, why we were able to limit the damage, and what's next.

The vulnerability

The exploited bug is in SignatureChecker._isValidContractSignature from Zodiac base contracts, inherited by Modifier (https://github.com/gnosisguild/zodiac/blob/master/contracts/core/Modifier.sol)

function _isValidContractSignature(
    address signer,
    bytes32 hash,
    bytes calldata signature
) internal view returns (bool result) {
    uint256 size;
    assembly { size := extcodesize(signer) }
    if (size == 0) {
        return false;
    }

    (, bytes memory returnData) = signer.staticcall( // <-- 'success' boolean is not checked
        abi.encodeWithSelector(
            IERC1271.isValidSignature.selector,
            hash,
            signature
        )
    );

    return bytes4(returnData) == EIP1271_MAGIC_VALUE;
}

The staticcall destructuring is not using the first return argument: (, bytes memory returnData) = signer.staticcall(...) , which is the bool success flag. The function then casts the first four bytes of returnData to bytes4 and compares to 0x1626ba7e , the EIP-1271 magic value. The attacker manipulated the signature field in such a way to force the Safe fallback handler to call an attacker deployed contract which always reverted with a 4-byte payload matching the EIP-1271 magic value. Because of how EVM handles reverts and the sequence of smart contract calls, the revert data ended up in the returnData which was then compared with the magic value.

This allowed the attacker to schedule any transaction on any Safe that had such a Delay module enabled.

Mitigation

We patched the contracts with this small fix. And deployed new mastercopies for both Roles and Delay modules. This is the same approach that Gnosis Pay took.

(bool success, bytes memory returnData) = signer.staticcall(...);
return success && bytes4(returnData) == EIP1271_MAGIC_VALUE;

Addresses

Delay.sol

https://etherscan.io/address/0xa0A3Eb0C60bbEdAd0d41AbfA2b9C0a8F91f7Ae34etherscan.io

Roles.sol

https://etherscan.io/address/0x732B9E9f259fbA6f65A1a012DC89c20872ffBd2fetherscan.io

We shipped UI which allows users to disable the vulnerable modules and provided a way for them to create a new vault with patched recovery modules and migrate the funds into a newly deployed vault.

Why Ante Vaults were not drained?

Our vaults had a default cooldown period of 3 months. Even if the hacker was able to submit a malicious transaction, the exploit did not allow him to bypass the cooldown period.

This gave us and our users enough time to react and disable the vulnerable modules.

Next steps

If you have a vault created on https://app.ante.org/vaults we advise you to go to your Ante Vaults dashboard and check for vaults that are tagged as "vulnerable". Open the vault and follow the instructions from that page to mitigate or migrate.