Notice: Editorial analysis with data as of June 9, 2026, based on the technical post-mortem by Verichains, the public history of the Zodiac repository on GitHub, and communications from Gnosis. It does not constitute financial or security advice. CleanSky does not receive commissions or referral payments from any of the projects mentioned.
The bug that drained approximately $265,000 from Gnosis Pay on June 1, 2026, had already been fixed in the source code since February 27. The patch existed, was merged, and was public and verifiable on GitHub. What failed was not the detection of the flaw, but its propagation: the contract deployed on-chain never received the correction because it was still compiled against an old dependency. This article is not just another DeFi hack report. It is a case study of a structural pattern that almost no one audits: the gap between a "bug fixed in the repository" and a "bug live on-chain." The affected module, the Zodiac Delay Module (a governance module that imposes a mandatory delay between transaction approval and execution to allow for vetoing), is open-source, audited, and used by dozens of protocols. And yet, the code protecting the funds was not the code running on the blockchain. We will reconstruct the exact timeline, explain why "open-source and audited" does not imply "secure in production," and provide an actionable checklist to verify that a deployed contract actually incorporates the latest patches.
What exactly happened on June 1?
On June 1, 2026, Gnosis Pay—the self-custodial debit card that spends balances directly from a user's Safe (a multisig smart contract wallet)—detected an active exploit against the Zodiac Delay Module v1.1.0 deployed on Gnosis Chain. The attacker drained around $265,000 spread across several victims before the team coordinated with bridge validators to pause operations and contain the movement of funds.
The module's mechanics are, on paper, a layer of protection. When a user wants to move funds outside the normal card payment flow, the transaction is queued and must wait for a cooldown period before execution. During that interval, a malicious transaction can be flagged as invalid and vetoed. It is the equivalent of a scheduled bank transfer that you can cancel within a security window. The Delay Module turns that window into code.
The exploit did not break the delay logic head-on. It attacked signature verification. The Delay Module—like much of the Safe ecosystem—validates certain operations using the ERC-1271 standard (the mechanism by which a smart contract, and not just a private key, can "sign" and authorize an action). The flaw allowed a contract call that had reverted (meaning it had failed) to be interpreted as a valid signature anyway. The attacker controlled the data returned by that failed call and, with it, fabricated an authorization that the module accepted as legitimate.
Why did a 2023 flaw detonate in 2026?
This is where it gets interesting, and where the timeline stops being an incident report and becomes a case study. The bug was not born in June 2026. According to Verichains' forensic reconstruction, the vulnerability was introduced on October 28, 2023, in commit 9a9e380 of the Zodiac code.
That commit changed how the contract handled a staticcall (a read-only call to another contract that should not modify state). In the modification, the success value—the boolean indicating whether the call succeeded or reverted—was discarded, leaving only the check for the "magic value" in the return data. Translated: the contract stopped asking "did this call work?" and started asking only "does the data you're returning have the right format?". Since the attacker controlled that return data even in a call that reverted, they could construct a response with the correct format starting from an operation that had actually failed.
For two and a half years, that flaw lay dormant. It wasn't exploited because it wasn't trivial to find and because it required a specific combination of conditions: an account with the Delay Modifier v1.1.0 (or Roles Modifier v2) enabled, alongside a Safe using a vulnerable fallback handler (the contract that manages calls not explicitly planned for) assigned as a module or role member. A specific configuration, but exactly the one Gnosis Pay's infrastructure had.
What was the "ghost patch" of February?
On February 27, 2026—three months before the exploit—the Zodiac team fixed the flaw. Merge commit 11708ac in the gnosisguild/zodiac-core repository—pull request #34, "Simplify Base Contracts," part of version v4.0.0-alpha.0—rewrote the base contracts. Among its changes, sub-commit f06f07b adjusted the EIP-1271 validation "to check staticcall success": that is, it re-inserted the question the 2023 commit had removed: "did this call actually work?".
The patch was correct. It was public. It was on GitHub, merged into the main branch, accessible to anyone who wanted to read it. And it was useless, because the contract guarding Gnosis Pay's money never received it.
The reason lies in dependency plumbing, not cryptography. The new, patched line of code lived in the zodiac-core package. However, the Delay Module instances in production were still compiled against the old package, @gnosis.pm/zodiac, a legacy dependency that never received the backport of the fix. The ecosystem had fragmented into two code lineages: the new one, where the bug was dead, and the old one, still in use, where it remained alive. The forensic question posed by Verichains is exactly that: why were Gnosis Pay's production instances still compiled against an obsolete dependency when a newer line existed that had already resolved this class of bug?
Why is a fix in the repository not a fix in production?
This is the heart of the matter and the part that superficial coverage skipped when titling "Gnosis Pay was hacked." A smart contract does not update itself just because someone merges a pull request on GitHub. The bytecode running on the blockchain is an immutable snapshot of the code as it was at the time of deployment. Merging an upstream fix does not touch that bytecode. For the fix to reach the chain, someone must recompile against the patched version and redeploy the contract (or, in upgradeable architectures, point the proxy to a new implementation). Until that happens, the repository and the chain diverge.
The analogy is that of any modern software deployment. A team fixes a security flaw in a library and publishes a new version. Your production service is not magically protected: it continues to run the container image you built months ago, with the old version of the library packaged inside, until you rebuild and redeploy. The difference is that in the cloud, redeploying is a routine command; on-chain, it is a costly operation, sometimes irreversible, and may require governance, user migration, or pausing the system. The incentive not to touch what "works" is much stronger. And that is why the gap between repository and production tends to widen over time, not close.
There is an aggravating factor regarding transparency that almost no one mentions. A public patch in an open-source repository is, to an attentive attacker, a map. The commit that fixes a bug describes the bug. Anyone monitoring the repositories of the most used security libraries can read a fix, deduce the vulnerability it corrects, and check which contracts in production have yet to apply it. The transparency that makes open-source reliable is, in the window between the fix and the redeployment, exactly the clue the adversary needs.
Where does the "open-source and audited" mental model go wrong?
The Gnosis Pay case dismantles several comfortable beliefs about why a crypto system "should" be secure. It is worth comparing them against operational reality.
| Naive Mental Model | Operational Reality |
|---|---|
| "The code is open-source, anyone can review it, so bugs are found quickly." | The bug lived for two and a half years in public code before being exploited. Open-source guarantees that it can be reviewed, not that someone will do it thoroughly or in time. |
| "It is audited." | An audit validates a specific version at a specific time. The production deployment may lag behind what was audited or derive from a different code lineage than the one reviewed. |
| "The flaw is already fixed in the repository, we are covered." | On-chain bytecode does not change when a PR is merged. Until redeployment, the contract continues to execute the vulnerable version. |
| "We use a standard and maintained library." | You may be compiling against a legacy package that no longer receives patches from the new line. The "standard" and "maintained" dependencies may have bifurcated. |
| "The Delay Module's delay gives me time to react." | The delay only protects if the logic deciding what gets executed is correct. The exploit didn't break the clock: it broke the validation of who had permission to queue transactions. |
None of these beliefs are absurd. They are all reasonable as starting points. The problem is treating them as guarantees rather than necessary but insufficient conditions. "Audited" reduces risk; it does not eliminate it, and it certainly does not cover the subsequent divergence between what was audited and what was deployed.
How did Gnosis, Zodiac, and Safe respond?
The response to the incident was, procedurally, fast and reasonably transparent. Gnosis paused the bridge by coordinating with validators to stop the outflow of funds. Co-founder Martin Köppelmann committed to fully reimbursing affected users: "Gnosis will cover all user losses," he posted on X.
The Zodiac team communicated that they had been working directly with affected accounts before the public disclosure and that, by the time the notice was made public, more than 95% of identifiable affected accounts had already taken corrective measures. Safe Labs, for its part, was quick to clarify the perimeter of the flaw: Safe smart contracts, Safe{Wallet} infrastructure and interface, and account recovery were not affected. The vulnerability was isolated to third-party Zodiac modules—Roles Modifier v2 and Delay Modifier v1.1.0—and was only triggered under the specific combination of conditions described earlier.
That distinction matters to avoid overstating systemic risk: it was not a flaw in the Safe core, which holds a massive fraction of the ecosystem's smart contract assets. But it should not be understated either: Zodiac modules are used by many protocols for governance and treasury management, and the lesson about dependency lineage applies to all of them.
How to verify that the deployed contract has the latest patches?
The actionable value of this case is that the repo-versus-production gap is auditable. It is not an invisible fatality. Both a protocol integrating third-party modules and an advanced user entrusting funds to a contract can check much of what failed here. This is the minimum checklist.
- Identify the exact version deployed, not the one in the repository. Read the verified contract code in production on the block explorer and note which library version it is compiled against. The number that matters is the on-chain bytecode, not the GitHub README.
- Check the package lineage. Distinguish whether the contract depends on the active package or a legacy one. In this case, the difference between
zodiac-coreand@gnosis.pm/zodiacwas the difference between being protected and not. A deprecated package may not receive security backports. - Follow security commits for the libraries you use, not just their releases. A fix may arrive in an alpha version or in an isolated commit months before an "official" release. Monitor the history, not just the version tags.
- Treat every upstream patch as a redeployment task, not a resolved event. Merging is not deploying. Maintain an inventory of which production contracts depend on which libraries and versions to know what needs redeploying when a fix appears.
- When a public patch appears in a library you use, assume it is public information for the attacker as well. The window between the fix and your redeployment is a race. Prioritize it as such.
- As a user, minimize hot balances. If a product holds funds in a contract with complex modules, keep only what you will use in the short term on-chain and review which modules you have enabled on your Safe.
None of these steps require being an auditor. They require treating deployment as part of the security surface, not just the code.
What pattern does this case leave for the rest of DeFi?
The Gnosis Pay exploit is the flip side of the software supply chain attacks that have marked 2026. In those, malicious code sneaks into a dependency and propagates to production unintentionally. Here, the opposite and, in some ways, more uncomfortable thing happened: legitimate and corrective code existed, but it did not propagate. The failure was not by the developers who found and fixed the bug. It was in the chain that was supposed to carry that fix from the repository to the bytecode guarding the money.
The structural lesson is that the security of a crypto system is not decided only in the code or only in the audit. It is also decided, and perhaps primarily, in deployment discipline: in knowing what version runs on the chain, what dependencies it is compiled against, and its lag relative to known patches. In an ecosystem that prides itself on transparency, the most opaque data is often precisely that: the distance between what the repository says and what the contract executes. Those who measure it will have a real security advantage over those who settle for the "open-source and audited" seal.
Related articles: Crypto Supply Chain Attacks: The Trust Paradox. $25 Million Stolen via Prompt Injection in AI Agents. Monitor your positions and wallets on CleanSky — to maintain visibility over where your balance is and which protocols are guarding it.