Worked example · 2026-06

Gnosis Pay — Zodiac Delay/Roles modifier fallback-handler bypass — 2026-06-01

Loss: undisclosed in absolute terms as of 2026-06-05. Gnosis Pay has not published a post-mortem loss figure; the live drain targeted EURe (Monerium euro stablecoin) and GNO held in user Safe smart-account cards on Gnosis Chain. The economically material fact is the operator commitment rather than the raw figure: co-founder Martin Köppelmann publicly pledged that Gnosis will cover all user losses, converting the incident from a depositor loss into an operator/treasury liability. Zodiac later reported that over 95% of identifiable affected accounts had already taken corrective action, which bounds the residual exposure but does not disclose the realised theft.
OAK Techniques observed: OAK-T9.004 (Access-Control Misconfiguration — the canonical anchor. A trusted, audited security modifier — Zodiac Roles Modifier v2 / Delay Modifier v1.1.0 — could be driven to authorise and execute an outbound transaction without the intended authorisation/cooldown predicate being satisfied, because of a composition flaw involving a vulnerable fallback handler on a Safe that had been assigned as a module or role member. The authorisation predicate the system relied on was evaluated against the wrong subject / under a configuration its designers did not anticipate. See techniques/T9.004-access-control-misconfiguration.md). OAK-T11.003 (In-Use Multisig Smart-Contract Manipulation — cross-referenced: the exploited surface is a Safe smart-account module/modifier layer, the same architectural layer as SquidRouterModule and UXLINK; here the manipulation rides a legitimate Zodiac modifier rather than a counterfeit one. See techniques/T11.003-multisig-contract-manipulation.md). OAK-T11 (Custody and Signing Infrastructure parent).
Attribution: pseudonymous attacker; on-chain addresses observed during the live drain, no public attribution to a named operator group. The exploit was active (transactions being mined in real time) when Gnosis Pay disclosed it, which is why the initial operator response was a network-level freeze rather than a forensic write-up.
Key teaching point: Gnosis Pay is the **2026 worked example of a security-control module being the attack surface — not because it was counterfeit, but because it was composed in a way its authors did not model.** OAK already carries the malicious-module shape (SquidRouterModule, May 2026: a counterfeit Safe module gating privileged execution behind a public constant string) and the delegate-call hijack shape (UXLINK, 2025-09). Gnosis Pay adds the trusted-module composition shape: the Zodiac Delay Modifier is a widely-deployed, audited Safe guard whose entire purpose is to add safety (a ~3-minute cooldown on outgoing transactions so a user can cancel a suspicious one). The flaw was not in the Delay Modifier's headline logic but in a fallback-handler interaction that only manifested when a Safe using a vulnerable fallback handler was itself enrolled as a module or role member of the guarded account. A security primitive that is correct in isolation became an authorisation bypass under a specific multi-Safe enrolment configuration — and because Gnosis Pay enrolls every card user's Safe behind the same modifier pattern, the flaw was systemic across the user base rather than isolated to one account.

Summary

Gnosis Pay issues self-custodial Visa debit cards backed by user-controlled Safe smart accounts on Gnosis Chain. To make a custodial-feeling card UX safe on a self-custody account, each card-Safe is guarded by Zodiac modifiers: a Delay Modifier enforces a short cooldown (~3 minutes) between when an outgoing transaction is queued and when it can execute, giving the user (and Gnosis Pay's monitoring) a window to cancel anomalous activity; a Roles Modifier scopes which actions a given module/relayer may take.

On 2026-06-01, an attacker found an implementation flaw that inverted this protection. Per Zodiac's disclosure, the vulnerability affected Roles Modifier v2 and Delay Modifier v1.1.0 and "only affected accounts where either the Roles Modifier v2 or Delay Modifier v1.1.0 module was enabled and where a Safe account using a vulnerable fallback handler had been assigned as a module or role member." Under that configuration, an attacker could bypass the verification gates and initiate outbound transactions directly from Safes that had the module enabled — i.e., move funds without satisfying the cooldown/role predicate the modifier was supposed to enforce. The drain primarily hit EURe and GNO balances.

Because the exploit was active when discovered, Gnosis's first move was containment at the network layer rather than a contract patch: the team paused the bridge and coordinated with Gnosis Chain validators to shut down all outbound bridge paths, cutting off the attacker's exit routes from Gnosis Chain to other networks. An early user-facing advisory urging manual self-withdrawal was deleted once the team recognised that most card users could not safely execute a manual withdrawal themselves (the same modifier machinery sat in the path). Köppelmann then committed that Gnosis would cover all user losses.

Zodiac followed with a public statement on 2026-06-03 emphasising that core Safe contracts were not affected — the flaw lived in the Zodiac modifier modules + fallback-handler composition, not in Safe itself — and that >95% of identifiable affected accounts had already remediated, with a full post-mortem to follow.

Why this is structurally significant

T9.004 (Access-Control Misconfiguration) is OAK's residual class for "an action that should have been gated was not, because the predicate was missing, evaluated incorrectly, or evaluated against the wrong subject." Gnosis Pay extends the class into a sub-shape the corpus had not anchored: the predicate lived inside a dedicated, audited security module, and the bypass came from how that module was composed with another Safe acting as its module/role member, via a vulnerable fallback handler.

Place it against the adjacent OAK module-layer cases:

Counterfeit-module sub-shape (SquidRouterModule, 2026-05). A malicious Safe module gated privileged execution behind a publicly-known constant string, so any caller could act as an authorised delegate (examples/2026-05-squidroutermodule-safe-module-constant-string-authorization.md). The defect is trust in an attacker-supplied module.
Delegate-call hijack sub-shape (UXLINK, 2025-09). A legitimate multisig's delegatecall surface was hijacked to execute attacker logic in the Safe's context (examples/2025-09-uxlink.md). The defect is an over-powerful call primitive on a trusted account.
Trusted-module composition sub-shape (Gnosis Pay, this case). A legitimate, widely-deployed Zodiac modifier behaved correctly in isolation but could be driven to skip its own gate when a Safe with a vulnerable fallback handler was enrolled as a module/role member. The defect is an unmodelled interaction between two individually-correct trusted components.

The three share a layer (Safe module/modifier authorisation) but differ in where the trust failed: in the provenance of the module (Squid), in the power of a call primitive (UXLINK), and in the composition of trusted modules (Gnosis Pay). The Gnosis Pay sub-shape is the hardest to catch with conventional single-contract auditing, because each component — Safe, Delay Modifier, Roles Modifier, fallback handler — can pass its own audit while the combination under a specific enrolment topology is what is exploitable.

The case also illustrates a fleet-wide blast radius from a shared configuration template. Gnosis Pay does not configure each card account bespoke; every user Safe is provisioned behind the same modifier pattern. A composition flaw in that pattern is therefore not one vulnerable account but the entire card base simultaneously — the smart-account analogue of a single misconfigured image deployed across a server fleet.

Timeline (UTC)

When	Event	OAK ref
Pre-2026-06-01	Gnosis Pay provisions card users' Safe smart accounts on Gnosis Chain, each guarded by Zodiac Delay Modifier (~3-min cooldown) and Roles Modifier; some Safes enrolled as modules/role members of others	(standing T9.004 / T11.003 surface)
2026-06-01	Attacker exploits a composition flaw (Roles Modifier v2 / Delay Modifier v1.1.0 + a Safe using a vulnerable fallback handler assigned as module/role member) to initiate outbound transactions directly from guarded Safes, skipping the cooldown/role gate; primarily drains EURe and GNO	T9.004 + T11.003 execution
2026-06-01	Gnosis Pay discloses an active exploit; posts (then deletes) a manual-withdrawal advisory after recognising most users cannot self-withdraw; pauses the bridge	(operator detection / containment)
2026-06-01	Gnosis coordinates with Gnosis Chain validators to shut down all outbound bridge paths, cutting the attacker's exit routes	(network-level containment)
2026-06-01	Co-founder Martin Köppelmann commits that Gnosis will cover all user losses	(operator response)
2026-06-03	Zodiac publishes a statement: flaw is in the Zodiac modifier modules + fallback-handler composition, core Safe contracts unaffected; >95% of identifiable affected accounts already remediated; full post-mortem pending	(vendor root-cause disclosure)

What defenders observed

Pre-event (configuration / composition layer): the exploitable condition required a specific topology — a Safe with a vulnerable fallback handler assigned as a module or role member of an account guarded by Roles Modifier v2 / Delay Modifier v1.1.0. Defender lesson: audit the composition graph of Safe modules/modifiers/fallback handlers, not just each contract in isolation. A fallback handler is an under-scrutinised extension point that can re-route calls; enrolling a Safe-with-fallback-handler as a module of another Safe creates an authorisation path that neither component's standalone audit covers.
At-event (on-chain signal): outbound transfers from card Safes that did not honour the Delay Modifier cooldown — i.e., execution without the expected queue→wait→execute interval — are the direct exploitation signature. A monitor that asserts the invariant "every outbound tx from a guarded Safe was queued ≥ cooldown ago" would have flagged the drain in real time, independent of knowing the root cause.
At-event (containment design): because the modifier machinery sat in the withdrawal path too, the naive "tell users to withdraw" response was unsafe and was retracted. The effective lever was upstream of exit: pausing the bridge and coordinating with validators to close outbound bridge paths. Defender lesson: for a self-custody fleet you cannot unilaterally drain to safety, the realistic emergency control is chokepoint containment at the exit (bridge/validator) layer, not per-account user action.
Post-event (blast-radius accounting): the ">95% already remediated" framing is a fleet-remediation metric, not a loss metric. For a shared-template smart-account fleet, the meaningful post-incident numbers are fraction of the fleet on the vulnerable configuration and fraction migrated to the patched configuration — track those alongside realised loss.

What this example tells contributors writing future Technique pages

T9.004 needs a documented trusted-module-composition sub-shape. It is distinct from the counterfeit-module (Squid) and delegate-call-hijack (UXLINK) sub-shapes: here every component is legitimate and individually correct, and the bypass is an unmodelled interaction surfaced only by a specific enrolment topology. Record which sub-shape a new Safe-module case belongs to — the audit guidance (audit the composition graph, not the components) is specific to this one.
A security control can be the attack surface. The Delay Modifier exists to add safety; the exploit turned it into the bypass. When a case's root cause is "the guard itself was driven to skip its gate," map it under T9.004 and note that the failed predicate lived in a dedicated security module — this is a higher-severity pattern than a missing modifier because operators reasonably believed the surface was protected, not unprotected.
Shared-template fleets convert one bug into a fleet-wide event. Where a provider provisions every user account from the same module template, record the blast radius as fleet-wide and the meaningful remediation metric as fraction-of-fleet migrated, not just realised loss.
Self-custody containment lives at the exit layer. Document that the operator could not safely withdraw on users' behalf and that the effective control was bridge/validator-level chokepoint containment. This is the self-custody analogue of an exchange freezing withdrawals, and it belongs in the defender-playbook section of any T11.003 / smart-account-fleet case.

Public references

[zodiacgnosispay2026] — Zodiac statement, 2026-06-03: flaw affects Roles Modifier v2 / Delay Modifier v1.1.0 where a Safe using a vulnerable fallback handler is assigned as a module/role member; core Safe contracts unaffected; >95% of identifiable affected accounts remediated; full post-mortem pending. Via Crypto Times, "Zodiac Reveals Flaw Behind Gnosis Pay Exploit, Safe Unaffected": https://www.cryptotimes.io/2026/06/03/zodiac-reveals-flaw-behind-gnosis-pay-exploit-safe-unaffected/
[cryptotimesgnosispay2026] — Crypto Times, "Gnosis Pay Pauses Bridge Following Active Zodiac Delay Module Exploit", 2026-06-01: https://www.cryptotimes.io/2026/06/01/gnosis-pay-pauses-bridge-following-active-zodiac-delay-module-exploit/
[defiantgnosispay2026] — The Defiant, "Gnosis Pay Hit by 'Delay Module' Exploit as Gnosis Pledges to Cover User Losses": https://thedefiant.io/news/hacks/gnosis-pay-hit-by-delay-module-exploit-as-gnosis-pledges-to-cover-user-losses
[cryptonewsgnosispay2026] — crypto.news, "Gnosis Pay exploit tied to Zodiac delay module as users exit": https://crypto.news/gnosis-pay-exploit-tied-to-zodiac-delay-module-as-users-exit/
Zodiac / Safe documentation — Delay Modifier (cooldown queue), Roles Modifier (scoped permissions), and Safe fallback-handler extension point.

Discussion

Gnosis Pay sits in the OAK Safe-module family alongside SquidRouterModule (counterfeit module), UXLINK (delegate-call hijack), and the Bybit / Safe{Wallet} 2025 UI-substitution case (examples/2025-02-infini.md and the T11.001 anchor) — but it is the cleanest example of a legitimate, audited security module becoming the exploited surface through composition. Where SquidRouterModule teaches "do not trust a module you did not vet," Gnosis Pay teaches the harder lesson: even a module you did vet can fail when composed with another trusted component in a topology its authors did not model. The Delay Modifier's audit covered the Delay Modifier; the exploit lived in the seam between it, the Roles Modifier, a fallback handler, and a Safe-as-module-member.

The case pairs naturally with the corpus's "shared-template blast radius" thread: like the SquidRouterModule incident's 86 Safes, Gnosis Pay's exposure spanned a fleet of user card-Safes provisioned from one modifier pattern, so a single composition flaw was a fleet-wide event. Contributors building out T11.003 and the smart-account-security-module cohort should treat module-composition auditing (the graph of modules/modifiers/fallback handlers, not the individual contracts) and exit-layer containment (bridge/validator chokepoints for fleets the operator cannot unilaterally drain) as the two distinguishing lessons of this incident.