Summary
On 1 June 2026, Gnosis Pay was hit by an active exploit related to its delay module. Zodiac subsequently disclosed that the underlying flaw affected the Roles Modifier v2 and Delay Modifier v1.1.0 when enabled on a Safe account using a vulnerable fallback handler as a module or role member. The Safe smart contracts, Safe{Wallet} infrastructure, account recovery, and the Safe UI were not affected, according to reporting. Gnosis pledged to cover user losses, replaced all affected Safe accounts, and restored normal card operations for more than 99% of users by 7 June. The loss amount has not been disclosed. The detailed root-cause writeup and full postmortem remain pending where not yet official.
What is confirmed and what is pending
The existence of the exploit, the affected Zodiac module versions, the fact that Safe core contracts and infrastructure were unaffected, and the recovery to 99%+ of users by 7 June are all reported by the sources cited below. The technical detail of the flaw is drawn from a Federico Kunze post and search results describing the Modifier base class and its EIP-1271 signature check. Specific attacker and victim contract addresses were not published in the sources used for this analysis, and are not invented here. Root cause and a detailed postmortem are still pending where not yet official.
Incident timeline
| Date | Event |
|---|---|
| 1 June 2026 | Active exploit related to Gnosis Pay’s delay module is reported. Gnosis pledges to cover user losses. |
| Early June 2026 | Zodiac discloses the flaw affects Roles Modifier v2 and Delay Modifier v1.1.0 under specific conditions. Safe core is reported unaffected. |
| By 7 June 2026 | Gnosis Pay replaces all affected Safe accounts and restores normal card operations for more than 99% of users. |
The reported flaw
The technical detail, as described publicly by Federico Kunze and corroborating search results, sits in the Zodiac Modifier base class. In @gnosis.pm/zodiac@3.4.1, SignatureChecker._isValidContractSignature discarded the boolean success flag returned by the external call and compared the first four bytes of the returned data against the EIP-1271 magic value 0x1626ba7e.
EIP-1271 lets a smart contract declare whether a signature is valid by implementing isValidSignature, which is expected to return the magic value 0x1626ba7e on success. The correct way to consume that interface is to check both that the external call succeeded and that it returned exactly the magic value. By discarding the success flag and only inspecting the leading bytes of the returndata, the check could be satisfied by returndata that happened to begin with the magic value, regardless of whether the call genuinely succeeded as an EIP-1271 validation. That turns signature validation into a far weaker test than intended.
The attack path described publicly is that an externally owned account could call execTransactionFromModule(to, value, data, operation) on a victim Delay Module, appending a 97-byte calldata trailer that encoded a forged contract signature. Because the flawed check would accept that forged signature, the caller could queue and execute arbitrary transfers through the module without holding the user’s private keys. The module’s authority over the account became reachable by an attacker who never controlled the account.
What was and was not affected
| Component | Status |
|---|---|
| Zodiac Roles Modifier v2 | Affected when enabled with a Safe using the vulnerable fallback handler as a module / role member |
| Zodiac Delay Modifier v1.1.0 | Affected under the same conditions |
| Safe smart contracts | Not affected, per reporting |
| Safe{Wallet} infrastructure | Not affected, per reporting |
| Safe account recovery | Not affected, per reporting |
| Safe UI | Not affected, per reporting |
Confirmed vs pending
| Field | Status | Detail |
|---|---|---|
| Incident date | Reported | 1 June 2026, active exploit related to Gnosis Pay’s delay module |
| Affected modules | Disclosed by Zodiac | Roles Modifier v2 and Delay Modifier v1.1.0 under specific conditions |
| Technical detail | Reported (Federico Kunze post / search) | Discarded success flag in SignatureChecker._isValidContractSignature; compared first four bytes of returndata to 0x1626ba7e |
| Attack path | Reported | EOA calls execTransactionFromModule with a 97-byte trailer encoding a forged contract signature |
| Loss amount | Not disclosed | Gnosis pledged to cover user losses |
| Specific attacker / victim addresses | Not published | Not available in the sources used; not invented here |
| Recovery | Reported | Affected Safe accounts replaced; 99%+ card operations restored by 7 June |
| Root cause / full postmortem | Pending | Detailed writeup still to be finalised where not yet official |
Why this matters
Ignoring a return value is a vulnerability, not a style issue. The whole exploit reduces to one mistake: a low-level call’s success flag was discarded and only the returndata was inspected. Solidity does not revert on a failed low-level call; it returns false and leaves it to the caller to check. Code that skips that check is trusting attacker-influenceable bytes to mean what it hopes they mean.
EIP-1271 has to be consumed exactly as specified. The standard’s safety depends on requiring both a successful call and an exact-match return of the magic value. Comparing only the leading bytes, or treating any returndata that starts with 0x1626ba7e as valid, weakens the contract-signature path to the point where a forged signature can pass. Signature validation is precisely the place where being approximately correct is the same as being wrong.
Modules inherit the authority of the account they sit on. A Zodiac module enabled on a Safe can act on that Safe. When the module’s own signature check is flawed, the blast radius is the full authority that the module holds over the account, even though the Safe contracts themselves were sound. The composition of safe components produced an unsafe whole.
What defenders can take from this
Always check the success flag on external calls. Any consumption of EIP-1271, or any low-level call/staticcall, must verify both that the call succeeded and that the returned data is exactly what the interface requires. Treat a discarded return value in a signature or authorisation path as a critical finding in review.
Review the trust composition, not just individual contracts. Each of the Safe, the Roles Modifier, and the Delay Modifier may be sound in isolation. The vulnerability lived in how they were wired together with a particular fallback handler. Security reviews of modular account systems need to enumerate which module can act on which account, and re-validate every authorisation check along that path.
Delay modules are a control, but only if their gate is sound. A delay module exists to insert a time buffer before sensitive actions execute. That buffer is worthless if an attacker can queue actions through a broken signature check in the first place. The delay protects against a compromised but honest queue; it does not protect against a forged authorisation that the module accepts as legitimate.
A clean, funded recovery is the difference between an incident and a crisis. Gnosis pledging to cover losses, replacing affected Safe accounts, and restoring 99%+ of users within a week is the kind of response that limits user harm. It depends on having the operational capability to identify every affected account and migrate it, which is a planning exercise that has to happen before the incident, not during it.
Sources
- Crypto Times, “Zodiac reveals flaw behind Gnosis Pay exploit, Safe unaffected”
- Crypto Times, “Gnosis Pay restores card services for 99% of users after exploit”
- CryptoNews, coverage of the Gnosis Pay / Zodiac incident
- Federico Kunze (fekunze) on X, technical detail of the Zodiac signature-check flaw
If your account architecture composes Safe accounts with Zodiac modules, custom fallback handlers, or any EIP-1271 contract-signature path, the question is not whether each piece was audited on its own. It is whether every authorisation check along the wired-together path verifies both call success and an exact return, and whether you can identify and migrate every affected account quickly if one of them is wrong. Security4Web3 can review your modular account composition, audit your signature-validation logic against the EIP-1271 specification, and help you build the account-migration capability that turns a disclosed flaw into a one-week recovery rather than a sustained loss.