Smart Contract Incident Report: Legacy Bridge Vulnerability
Summary
On December 10, 2025, we were notified of unauthorized activity on a legacy version of the Bridge contract. This activity resulted from the legacy contract not being properly decommissioned during our April 2025 vulnerability response.
While the primary Bridge contracts were secured in April, the legacy contract remained active on-chain, allowing an attacker to access funds from users who had set unlimited token approvals. Native token balances were not affected.
We have permanently disabled the legacy contract across all supported networks. Our analysis confirms that exploitation was limited to a single user wallet on Ethereum Mainnet.
The vulnerability is fully remediated and no user wallets or funds remain at risk.
Technical Analysis
Background
On April 10, 2025, we identified a front-running vulnerability in the Bridge contracts that allowed unauthorized callers to misuse ERC20 token approvals granted to the contracts. To mitigate this, we immediately paused the affected contract and rolled out a fix on the same day.
The Incident Vector
However, a legacy version of the Bridge contract (0x81d57DD01a15BC1C19563693902df621500D4d2A) was not properly decommissioned during our response to the April 10th vulnerability. Our engineering teams prioritized securing the current version of the Bridge contract (0xA36E052aB76076355b25909c23D5f61D43FE9631).
We failed to brick the legacy contract. It should have been immediately upgraded to a null implementation to eliminate all risk. Because it remained live on-chain, an attacker was able to identify and exploit it.
The attacker was able to drain funds from users who had set unlimited ERC20 approvals through their wallet. The thirdweb SDK follows security best practices by defaulting to fixed-amount approvals to limit exposure, but users who bypassed these safety caps had their approved tokens at risk. Native token balances were not affected.
Immediate Mitigation
Upon identifying the vector on December 10th, we executed a contract upgrade. Because the legacy contract could not be paused via standard administrative functions, we upgraded the proxy to a null implementation across all supported chains, permanently disabling the contract.
Impact Analysis
We analyzed all activity on the affected legacy contract address from April 10th.
- Ethereum Mainnet: Malicious transactions were identified affecting a single wallet.
- Other Networks: No malicious transactions were identified on any other network.
Prior Communication (April 10th Incident)
Following the initial discovery on April 10th, we employed a targeted disclosure strategy. We identified developers who had integrated with the product and communicated with them directly to secure their user assets, prioritizing immediate mitigation to prevent widespread exploitation while fixes were implemented.
Timeline
- April 10, 2025: Vulnerability identified. The main contract (
0xa36e...9631) was paused and a fix was rolled out. The legacy contract (0x81d5...4d2A) was left unpaused. Impacted developers notified. - December 10, 2025: Report received regarding unauthorized funds movement.
- December 10, 2025: Investigation confirmed unpaused legacy contract as the vector.
- December 11, 2025: Contract upgrade executed; legacy contract permanently disabled.
Process Improvements
We are committed to learning from every incident to strengthen our security posture. Following this event, we are implementing the following improvements:
- Expanded Disclosure: We recognize that our reliance on developer outreach in April limited the broad visibility of this issue. In future incidents, we will implement a more aggressive disclosure policy to ensure end-users are directly informed and can take action, rather than relying solely on intermediaries.
- Post-Incident Review Process: We are requiring a mandatory follow-up debrief two weeks after any incident disclosure to review and verify completion of all remediation checklist items, ensuring nothing falls through the cracks
- Stricter Deployment Controls: We are strengthening our internal development processes, including stricter security requirements for smart contract development, comprehensive tracking of all deployed contracts, and mandatory inclusion of emergency intervention mechanisms in all protocol contracts. This ensures no contract can fall outside our operational oversight and enables rapid on-chain response to any incident.