Dozens of GnosisPay Wallets drained: A deep dive into a bold attack

On June 1, 2026, an unknown attacker drained funds from dozens of user wallets on the GnosisPay service within the Gnosis Chain. The root cause was a vulnerability in the Delay module, which is responsible for additional transaction verification and execution delays. GetBlock AML Research breaks down the attack and the subsequent movement of stolen assets.

Why Fake Smart Contracts Were Needed

The flaw was in the digital signature verification mechanism. The module used a function called moduleTxSignedBy(), which was supposed to confirm that a transaction had indeed been approved by the wallet owner. However, the verification data was pulled directly from a part of the request that the attacker could fully control.

By using a specially crafted data structure with multiple layers of nested signatures, the attacker tricked the system into first querying a third-party Biconomy Safe wallet, and then redirecting the verification to their own malicious contract. This contract always returned a response that the system interpreted as a valid signature.

As a result, the module mistakenly treated the fraudulent transactions as legitimate and allowed them to be executed.

The attacker then queued up 41 transactions, waited out the mandatory delay period enforced by the Delay module, and executed them. Each transaction transferred digital assets (EURe and GNO) from victim wallets to addresses controlled by the attacker.

Total estimated losses: ~$265K.

Attacker’s Ethereum network addresses:

• 0x81BA8A2b895D30280bca199C2Ff75f3F058d4C6c
• 0xf6a9f265012130d02fda1f39f74e9faf8388d2f6

Attack Timeline

The hacker pulled off a multi-layered attack using dozens of fake smart contracts.

May 29, 2026, 13:29:55 UTC

Several days before the withdrawal, the attacker deployed 41 separate malicious contracts. These contracts were specifically designed so that when their signature verification function isValidSignature() was called, it would always return 0x1626ba7e — a special EIP-1271 status code that normally means the signature is valid.

June 1, 2026, 05:26:10 UTC

The attacker called the Delay.execTransactionFromModule() function. The first part of the submitted data was interpreted by the system as a standard transaction containing the recipient address, transfer amount, additional data, and operation type. This part was queued for execution.

Inside the data field were commands to transfer EURe and GNO tokens from victim wallets to the attacker’s addresses. The verification process passed through the following function chain:

Delay.execTransactionFromModule() → moduleOnly() → moduleTxSignedBy()

The key detail: moduleTxSignedBy() did not only analyze the expected part of the data, but also an extra message field that the system didn’t parse in advance. The attacker placed specially crafted signature parameters , and v in this hidden section.

The values used were:

• v = 0x24400
• r = 0x7f59e536f083a63b67adfe3bc793a47744dba7d80
• s = 0xd957b7cc73ae8d40082124eb2a67284d8e287babfe4e6859f0772a1eab8c54af

The system interpreted the r value as the signer’s address and sent a request to 0x7f59e536f083a63b67adfe3bc793a47744dba7d80. That address belonged to a Biconomy Safe wallet. Then another signature verification process began inside the Safe itself:

0x1626ba7e() → Safe.0x20c13b0b() → Safe.checkSignatures()

At this stage, the signatureSplit() function extracted a different r parameter, which pointed to a pre-deployed malicious contract at:0x5a77953caa27ed4638f4dfdc665b8064d0e97a35. This address was set as the currentOwner and used for the next round of signature verification. The actual signature itself didn’t matter at this point.

The malicious contract was programmed to always return the EIP-1271 code 0x1626ba7e, regardless of input. During verification, the call failed, but that didn’t cancel the entire transaction. The system received the returned 0x1626ba7e value and accepted it as confirmation of a valid signature.

After that, the malicious transaction was successfully added to the execution queue. In total, the attacker queued 41 transactions and then waited several days for the delay period required by the security mechanism.

June 1, 2026, 05:57:35 UTC

After the waiting period ended, the attacker called the Delay.executeNextTx() function. This triggered the previously prepared commands, transferring EURe and GNO from victim wallets to the attacker’s addresses. The target address for each operation was a specific victim’s Gnosis Safe wallet, which had been specified during the attack preparation phase.

Root Cause of the Vulnerability

The main cause of the incident was a logic flaw in the signature verification chain:

Delay.execTransactionFromModule() → moduleOnly() → moduleTxSignedBy()

The system extracted the r, s, and v signature parameters from the end of a message fully controlled by the attacker. The r value was particularly important — it was interpreted as the signer’s address and used to verify the operation’s authenticity. The attacker structured the message to contain two levels of r, s, and v parameters.The first r parameter redirected verification to the Biconomy Safe wallet. The second r parameter pointed to pre-deployed malicious contracts that always returned the required EIP-1271 confirmation code. Thanks to this multi-layered scheme, the system mistakenly treated the fraudulent transactions as legitimate.

Movement of Stolen Funds

After the successful attack, the funds began moving across different blockchain networks. The attacker’s wallet 0x81BA8A2b895D30280bca199C2Ff75f3F058d4C6c transferred approximately $246K in USDT from the Ethereum network to the Hyperliquid network.

From there, the funds were sent to:0xb1834575349c6eb56675c35b4109c3d3a77dd2fc

At this address, part of the assets was swapped for Monero (XMR), a cryptocurrency known for its enhanced transaction anonymity. As of the time of this report, the attacker’s wallet still held:

• 147,494.91 USDC
• 1.5174 ETH (~$2,700)
• 28.32 XMR (~$9,903)

Additional Monero holdings were distributed across four separate wallets: