Developers

Post-Mortem: Gnosis Pay Vulnerability Exploit

by Alexandru Popescu

On 1 June 2026, attacker(s) exploited a vulnerability that directly affected software modules (Delay Module & Roles Module) used in connection with the Gnosis Pay card safe infrastructure. This resulted in certain user safe wallets, and the funds stored there, either being compromised or at risk of compromise.


The team quickly contained the issue, taking card services offline and co-ordinating with partners to isolate attacker accounts, while keeping partners and users informed, and guaranteeing user funds.


The attacker(s) were able to extract a total of $1.5m. An additional ~$300k was rendered inaccessible and we are exploring recovery options.


Gnosis absorbed the losses and all funds were restored to users.

The Timeline

When
What

1 Jun 2026

Monitoring flagged the attacker's first large unauthorized transfer at 06:17 UTC and, following verification, the emergency response was initiated.

Root cause identified as a vulnerability in the Zodiac modules at 08:06 UTC.

1 Jun 2026

Card services taken offline. Bridge to Gnosis Chain paused by bridge validators. Attacker-linked addresses shared with stablecoin issuers to isolate where possible.

1–2 Jun 2026

Gnosis leadership proactively notified external projects that were at risk from the same vulnerability.

The Zodiac modules were repaired and shared with ChainSecurity for a focused review.

3 Jun 2026

On the evening of Wednesday, June 3rd, the first accounts were reactivated, including account balance restoration, card re-enabling, and resumption of normal operations.

An emergency fund was established and made available for users in extremis.

4 Jun 2026

ChainSecurity completed their review, the modules were also reviewed by internal teams, and we began the phased resumption of services.

4–7 Jun 2026

We deployed newly engineered card safe modules in tranches, linking to users' existing profiles. This was followed by phased restoration of full account balances and resumption of normal services.

6 Jun 2026

Full services restored to 99% of users, with the remaining accounts restored early the following week.

No users lost funds in the exploit.

Description of the Exploit

The attack was rapidly detected by treasury manager, NOCA, via their monitoring infrastructure. We immediately triggered our incident response protocol and identified the root cause within 2 hours.


The impact was isolated to the card safe software module components (specifically the Delay and Roles Modules provided by Zodiac). To ensure containment during the active triage phase, we systematically paused card transaction processing, authorisation systems, and new user onboarding.


To let an account owner move funds without holding native gas tokens, the account confirms requests with a signature check. It uses a standard method, ERC-1271, which asks a contract a yes-or-no question: is this signature valid?


The check read the answer the contract returned. It did not check whether the call had succeeded. Attacker(s) could deploy a contract that fails on purpose while still returning the "valid" code. To the account, a forged approval looked real. That let the attacker(s) queue withdrawals from accounts they did not own.


The vulnerability entered the Zodiac code in version 3.4.0, released on 30 October 2023, when signature support was added (commit 9a9e380).


The flawed check worked like this:


// Vulnerable: the success of the call is discarded.
(, bytes memory returnData) = signer.staticcall(
    abi.encodeWithSelector(isValidSignature, hash, signature)
);
return bytes4(returnData) == EIP1271_MAGIC_VALUE;
// A contract that reverts but returns the magic value is treated as valid.
// Vulnerable: the success of the call is discarded.
(, bytes memory returnData) = signer.staticcall(
    abi.encodeWithSelector(isValidSignature, hash, signature)
);
return bytes4(returnData) == EIP1271_MAGIC_VALUE;
// A contract that reverts but returns the magic value is treated as valid.
// Vulnerable: the success of the call is discarded.
(, bytes memory returnData) = signer.staticcall(
    abi.encodeWithSelector(isValidSignature, hash, signature)
);
return bytes4(returnData) == EIP1271_MAGIC_VALUE;
// A contract that reverts but returns the magic value is treated as valid.
// Vulnerable: the success of the call is discarded.
(, bytes memory returnData) = signer.staticcall(
    abi.encodeWithSelector(isValidSignature, hash, signature)
);
return bytes4(returnData) == EIP1271_MAGIC_VALUE;
// A contract that reverts but returns the magic value is treated as valid.


The fix is small. Also require the call to succeed:


(bool success, bytes memory returnData) = signer.staticcall(...);
return success && bytes4(returnData) == EIP1271_MAGIC_VALUE;
(bool success, bytes memory returnData) = signer.staticcall(...);
return success && bytes4(returnData) == EIP1271_MAGIC_VALUE;
(bool success, bytes memory returnData) = signer.staticcall(...);
return success && bytes4(returnData) == EIP1271_MAGIC_VALUE;
(bool success, bytes memory returnData) = signer.staticcall(...);
return success && bytes4(returnData) == EIP1271_MAGIC_VALUE;


The initial exploit contract is verifiable here: 0x5a77953caa27ed4638f4dfdc665b8064d0e97a35.


A signature patch was flagged as a security fix by the Zodiac team on 5 June 2026 (days after the exploit began).

The Amounts Involved


Amount

Taken by the attacker(s)

~$1.5M

Funds in inaccessible accounts

~$300k

Total

~$1.8M across 5,281 wallets with balance ≥ $1


Assets taken by the attacker(s):


Asset
Taken (USD value)

GNO

641,159

EURe

453,175

USDC.e

399,121

SAFE

2,202

WETH

323

xDAI

135

USDC

28

USDT

7

Total

~1,496,151

Actions Now Underway

Growing the security team.

We are growing the security team and bringing in external researchers to work alongside them, adding dedicated capacity.

Conducting a full internal review of our security practices.

We have an ongoing review of onchain and offchain systems: smart contracts, infrastructure, processes, and dependencies we rely on.

Completing an independent, holistic security assessment.

We are re-assessing our codebase and infrastructure end-to-end with an external security firm, giving us an outside perspective.

Widening our audit scope.

We have extended our smart contract audits to also cover external contracts we depend on.

Actively monitoring dependencies.

We actively monitor the dependencies we rely on, with a clear process to review and act on upstream security fixes quickly.

Rolling out the new Gnosis Pay product (known internally as v2).

We recently completed a full rebuild of the Gnosis Pay product and it is optimized for observability and streamlined operations. That observability ensures our ability to respond rapidly in future.

MORE ARTICLES
MORE ARTICLES
Last Updated: July 3, 2026 at 1:53 PM