Full Report
Optimism is a L2 blockchain and Wintermute is a liquidity provider. Optimism sent funds to Wintermute on the L2 chain but it should have been on mainnet ETH. So, nothing should happen, right? Wintermute's mainnet safe from deployed using an older version of the Proxy Factory; earlier than the first Optimism deployment. The Safe that was deployed uses a non-EIP-155 (replay attack prevention) compliant deployment! An attacker can replay the deployment with the Proxy Factory used by Wintermute on Optimism. The safe was created using the CREATE opcode, which uses the contracts nonce to determine the address. By creating enough contracts (8884), one will have the proper nonce and deploy to the proper address. They had now grabbed the address that Optimism sent the funds to. The Gnosis Safe deployed there could now retrieve the lost funds for themselves. Interesting vulnerability that required a lot of things to go wrong. Pretty neat!
Analysis Summary
# Vulnerability: Replayable Gnosis Safe Deployment Leading to Asset Loss on L2
## CVE Details
- CVE ID: N/A (This appears to be a specific incident/logic flaw outside of a standard CVE, though analogous to replay vulnerabilities)
- CVSS Score: N/A
- CWE: CWE-668 (Use of Hard-coded Credentials/Improper Trust Boundary) or CWE-15 (Improper Initialization) due to reliance on outdated non-EIP-155 deployment logic.
## Affected Systems
- Products: Gnosis Safe (specifically L2 deployments utilizing older Proxy Factory versions)
- Versions: Gnosis Safe Proxy Factory versions older than the one deployed on Optimism (e.g., Factory v1.1.1 vs Optimism deployment minimum v1.3.0).
- Configurations: Deployment utilizing the `CREATE` opcode based on contract nonce, resulting in a non-EIP-155 compliant deployment address generation.
## Vulnerability Description
The vulnerability stems from a specific scenario where a Gnosis Safe was deployed on the second layer (L2) solution, Optimism, using an older version of the Proxy Factory (e.g., v1.1.1). This older deployment method deliberately used a non-EIP-155 compliant transaction pattern.
Crucially, the address used to deploy the vulnerable Safe was derived using the `CREATE` opcode, which incorporates the deploying contract's nonce. An attacker could calculate or brute-force the required nonce by deploying many dummy contracts (8884 were mentioned) on Optimism until the attacker achieved the specific nonce that mirrored the deployment nonce used on Ethereum Mainnet (L1). This process resulted in the attacker deploying their *own* version of the Proxy Factory on Optimism at the **exact same address** that Optimism mistakenly sent funds to. Once the attacker controlled the address, they deployed the Safe using the malicious factory, recovering the funds sent in error by Optimism.
## Exploitation
- Status: Exploited (The funds were successfully stolen in the reported incident).
- Complexity: High (Required deep knowledge of L1/L2 address derivation similarities, nonce manipulation, and knowledge of the specific factory version mismatch).
- Attack Vector: Network (Interacting with the L2 network).
## Impact
- Confidentiality: Low (Not the primary impact)
- Integrity: High (Funds were successfully transferred to an unauthorized party)
- Availability: Indirect (Loss of funds for the intended L2 recipient)
## Remediation
### Patches
- This incident highlights a need for strict enforcement of **EIP-155 compliance** across Layer 2 rollups for address derivation when using legacy deployment patterns.
- The issue was resolved by the attacker successfully extracting the funds, acting as a critical failure point check on L2 deployments/interoperability handling of legacy contracts.
- Future versions of Proxy Factories should mandate EIP-155 serialization for all deployments to prevent cross-chain address replayability.
### Workarounds
- **EIP-155 Enforcement:** Ensure that L2 rollups strictly enforce EIP-155 rules for all transactions originating from L1, or reject transactions that attempt address replay based on nonce management when dealing with cross-chain asset transfers.
- **Address Verification:** Before sending assets to a newly generated address on an L2, verify that the contract deployed at that address matches the expected, authorized deployment mechanism for that network, especially when interacting with funds that were intended for L1/a different standard.
## Detection
- Indicators of Compromise: Unexpected contract deployment using a legacy factory version immediately preceding a massive fund withdrawal from an escrow/holding address.
- Detection Methods and Tools: Monitoring deployment transactions on L2s for the use of non-standard or older proxy factory bytecode signatures that do/did not include EIP-155 protection.
## References
- Vendor Advisories: N/A (This was a specific operational failure rather than a standardized software vulnerability advisory).
- Relevant Links:
- [Analysis discussing the OP theft mechanism](https://paragraph.com/@banteg/how-did-a-hacker-steal-op)