Gnosis Pay halted after Zodiac Delay Module exploit; Gnosis to cover losses

Gnosis co-founder Martin Köppelmann confirmed on June 1 that Gnosis Pay — the self-custody Visa card service that sits on top of user-controlled Safe accounts — was under active exploitation through a Zodiac module vulnerability. The attacker could initiate outbound transactions directly from affected Safes, bypassing the time-delay safety gate that Gnosis Pay relies on. Gnosis halted outbound bridge paths by coordinating with validators and has pledged to make all users whole. The exact total drained has not been published.

What happened

Köppelmann's initial public statement, posted on X on June 1, read in full as cited by The Block: "Unfortunately, there is a hack related to Gnosis Pay and the 'delay module.' Please be patient while we try to contain the damage. Rest assured, Gnosis will cover all user losses." The Block's coverage of the disclosure is here: Gnosis will cover all user losses amid exploit related to Gnosis Pay, co-founder Koppelmann says.

An earlier Köppelmann tweet asked Gnosis Pay users to immediately withdraw GNO and EURe; he subsequently deleted it, writing that "most users will not be able to" execute manual defensive withdrawals fast enough and that the team was working to contain the damage centrally. The Defiant tracked the deletion and the follow-up statement: Gnosis Pay Hit by 'Delay Module' Exploit.

Gnosis asked the validator set running the Gnosis Chain bridges to pause outbound transfers while containment was in progress. As of the initial round of reporting, Gnosis Pay had not published a loss estimate, the bridge had not been formally restarted, and no post-mortem or attacker address had been released to the public.

Mechanism — Zodiac module fallback handler bypass

On June 2, Zodiac (the Gnosis Guild project that maintains the Safe-module library used by Gnosis Pay) published a security update on X identifying the root cause. As reported by crypto.news, Gnosis Pay exploit tied to Zodiac delay module as users exit, and CryptoTimes' follow-up Zodiac Reveals Flaw Behind Gnosis Pay Exploit, Safe Unaffected, the vulnerability is constrained to two modules in two specific versions:

• Zodiac Delay Modifier v1.1.0 — repo: gnosisguild/zodiac-modifier-delay
• Zodiac Roles Modifier v2 — repo: gnosisguild/zodiac-modifier-roles

The pre-condition Zodiac identifies is narrow but consequential: the bug only fires on a Safe account that has one of those modules enabled and uses a vulnerable fallback handler set as a module or as a role member. Under that combination, the exploit primitive lets an attacker call into the modifier path and have it execute as if the time-delay queue or role check had been honoured — short-circuiting the protection the module exists to provide.

Zodiac was specific about what is not affected:

• Safe smart contracts themselves
• Safe{Wallet} infrastructure (the wallet UI and signer flow)
• Safe account recovery
• Any Safe that does not have the Roles Modifier v2 or Delay Modifier v1.1.0 module enabled with the vulnerable fallback handler configuration

Zodiac said the team had been working with affected projects privately before public disclosure and that, as of the disclosure, more than 95% of identifiable affected accounts had already taken corrective action.

Impact and counterparty exposure

• Scope is wider than Gnosis Pay. Köppelmann said the Zodiac disclosure represents the root cause of the Gnosis Pay incident and that several other projects beyond Gnosis Pay were affected. Zodiac handled those notifications privately before going public.
• Gnosis Pay users with active cards had their underlying Safes drained through the modifier path, not through any Safe-level compromise. Pre-existing GnosisPay Safes that still hold balances and have the vulnerable module configuration are the at-risk population.
• No GNO, EURe, or Gnosis Chain protocol risk. The bug is in two Gnosis Guild Zodiac modules, not in Gnosis Chain consensus, Gnosis Beacon Chain validators, the canonical Gnosis Chain bridge code, or the EURe issuer contract.
• Gnosis is covering losses. Köppelmann's compensation pledge is unconditional in his X posts — no carve-outs by loss size or by whether a user attempted to withdraw. The reimbursement mechanism and timeline have not been published.

What to watch

1. The official Gnosis Pay post-mortem. It should confirm: which exact fallback handler is the vulnerable one, the attacker's address(es), at least one drain transaction, the total loss in EUR/USD, and the reimbursement schedule. None of those are public yet.
2. The Zodiac GitHub advisories. As of writing, the security advisories tab for zodiac-modifier-delay is empty. A formal CVE / GHSA filing on either of the two affected repos is the durable artefact the wider ecosystem will integrate against.
3. Restart of Gnosis Chain outbound bridges. Until Gnosis posts that validators have lifted the pause and explicit migration guidance for module users is published, downstream Gnosis Chain bridge UX stays in the "contain" phase.
4. Other affected projects naming themselves. Köppelmann said several Zodiac users beyond Gnosis Pay are exposed. Watch the Safe / Gnosis Guild ecosystem (treasuries, DAO multisigs, Karpatkey-managed Safes, custody products) for disclosure threads.

Context — modular Safe stacks, the new attack surface

The Safe + Zodiac architecture is the dominant pattern for permissioned-but-self-custodial flows: a Safe at the root, with role-based Modifier modules on top to delegate constrained powers (DCA bots, payroll, payment cards, DAO sub-treasuries). The promise is that the Safe's signature scheme stays the trust root and the modifier layer narrows what a delegate can do. This exploit inverts that: a flaw in the modifier layer let calls execute as the Safe without traversing the Safe's signature path.

It is the same shape Blockchain Posts has documented in the past year — recent examples in our archive include the Gravity Bridge $5.4M signing-key drain, where validator-signed bridge logic was the soft target, and the StablR / EURR / USDR multisig minting compromise. The pattern: the smart contracts behaved as written; an off-chain or adjacent layer's key, fallback handler, or signer path is what failed. Modular Safe stacks add convenience; they also add a second contract surface that needs the same audit rigour as the Safe itself.