Zodiac (@zodiaceco) has published a full post-mortem of the security incident that affected Zodiac Roles Modifier v2.1.0 and Delay Modifier v1.1.0 on June 1. In its post, Zodiac said the report explains what happened, how the team responded, and what has changed since the incident. The post was published at 16:23 on June 19, 2026, and the page showed 3,850 views, along with interaction counters displayed as 6, 40, and 16.
A failed ERC-1271 check could be made to look valid
According to Zodiac, the root cause was in the ERC-1271 contract-signature check used by its modules. The check accepted a signature based only on the returned magic value and did not also verify that the call itself had succeeded. Zodiac said this meant a failed check could be made to appear valid, allowing module authentication to be bypassed.
The affected versions named in the post were Zodiac Roles Modifier v2.1.0 and Delay Modifier v1.1.0. Zodiac framed the issue as a defect in the module authentication path for those versions, rather than a broad problem affecting every user or every configuration. The post did not expand the scope beyond the affected module versions it explicitly listed.
The exploitable setup was narrowed to a specific Safe configuration
Zodiac said the issue was exploitable only in one narrow configuration: a Safe using the CompatibilityFallbackHandler assigned to an affected module. That configuration boundary was an important part of the post-mortem, because Zodiac also stated that EOA role members were never at risk and that setups without an affected module were never at risk.
In other words, the risk described by Zodiac required the combination of a Safe, the CompatibilityFallbackHandler, and an affected module. The company did not describe the issue as covering all Safe usage or all Zodiac deployments. Its explanation placed this scoping immediately after the technical root cause, clarifying which users were exposed and which setups were excluded.
Private contact, public disclosure, and whitehat recovery
After detecting the issue, Zodiac said it privately contacted affected users. The team also shipped a self-service checker and a remediation app, then made a public disclosure on June 2. Zodiac further said it ran whitehat recovery as part of the response.
The post included two key figures about the outcome. Zodiac said more than 99% of at-risk value was secured. It also said confirmed realized loss outside Gnosis Pay was approximately $4,500. The post did not provide additional loss figures beyond that statement.
Zodiac also thanked the users, integrators, Gnosis, Safe, SEAL 911, and independent researchers who helped identify, contain, and remediate the issue. The response described in the post therefore included several stages: private outreach, tooling for self-checking and remediation, public disclosure, whitehat recovery, and coordination with named ecosystem participants.
Patched contracts, independent audit, and restored service
As of the publication of the post-mortem, Zodiac said the contracts had been patched and independently audited. It also said all Zodiac apps had been updated and that service was fully restored. The full post-mortem was referenced at engineering.gnosisguild.org/posts/zodiac-p…, and Zodiac listed the security reporting channel as [email protected].
The central technical takeaway from Zodiac’s own account is that the ERC-1271 contract-signature check accepted the returned magic value without confirming call success. In the affected configuration, that allowed a failed validation call to be treated as valid and bypass module authentication. Zodiac’s post-mortem also set out the affected product versions, the narrow Safe configuration involved, the remediation timeline, the public disclosure date of June 2, the whitehat recovery process, the figure that more than 99% of at-risk value was secured, and the confirmed realized loss of about $4,500 outside Gnosis Pay.