The Web3 development ecosystem faced a significant security scare on December 5, 2023, when ThirdWeb, a widely used smart contract deployment platform with over 70,000 developers, publicly disclosed a critical vulnerability affecting its pre-built smart contracts. The flaw, rooted in an incompatibility between the ERC-2771 meta-transaction standard and Multicall functionality, threatened a broad range of NFT and token contracts across the Ethereum ecosystem and beyond.
The Exploit Mechanics
At the heart of this vulnerability lies a subtle interaction between two trusted open-source libraries. The ERC-2771 standard enables meta-transactions, allowing users to interact with smart contracts without paying gas fees directly. When combined with Multicall — a pattern that batches multiple function calls into a single transaction — the interaction creates an opening for address spoofing attacks. Specifically, an attacker could manipulate the msg.sender value within a meta-transaction context, effectively impersonating any address and executing actions on behalf of other users without their consent.
The affected contracts include ThirdWeb’s DropERC20, ERC721, ERC1155 across all versions, and AirdropERC20. These are among the most commonly deployed contract templates in the Web3 space, used for NFT mints, token distributions, and marketplace operations. ThirdWeb became aware of the vulnerability on November 20, 2023, and worked for two weeks to understand the full scope before making the public disclosure.
Affected Systems
The reach of this vulnerability extends well beyond ThirdWeb’s own contracts. Because the flawed code resides in a commonly used open-source library, any project that incorporated the same ERC-2771 and Multicall pattern could be affected. NFT collections deployed using ThirdWeb’s pre-built templates before November 22, 2023, are specifically at risk. Projects operating marketplaces, gaming contracts, minting platforms, and wallet integrations built on ThirdWeb’s infrastructure all fall within the vulnerability’s scope.
With Bitcoin trading around $44,080 and Ethereum at $2,293 on the day of the disclosure, the total value locked in potentially affected contracts represents hundreds of millions of dollars in digital assets. The fact that no exploitation had been detected prior to the disclosure speaks to both the subtlety of the vulnerability and the limited window of opportunity for responsible disclosure.
The Mitigation Strategy
ThirdWeb responded with a multi-pronged approach. First, the company developed and deployed a mitigation tool allowing contract owners to patch their deployed contracts without requiring a full migration. Second, they coordinated with the maintainers of the underlying open-source library to issue a fix upstream. Third, they recommended that all users revoke token approvals on affected contracts using platforms like revoke.cash, as suggested by DefiLlama developer 0xngmi.
In a show of commitment to ecosystem security, ThirdWeb doubled its bug bounty payouts from $25,000 to $50,000 and committed to covering mitigation costs for affected users through a dedicated grant program. The company also pledged to implement more rigorous auditing processes for all future contract releases.
Lessons Learned
The ThirdWeb incident underscores several critical truths about Web3 security. First, even trusted, widely-used open-source libraries can harbor subtle vulnerabilities that escape detection for extended periods. The combination of two individually secure components — ERC-2771 and Multicall — created an emergent vulnerability that neither component exhibited in isolation. This class of composability bugs represents one of the most challenging categories in smart contract security.
Second, the incident highlights the importance of rapid, coordinated disclosure. ThirdWeb’s two-week internal investigation window allowed them to develop mitigation tools before public disclosure, potentially preventing exploitation during the most vulnerable period. Third, the scale of impact — affecting contracts across the entire Web3 ecosystem — demonstrates how platform dependencies create systemic risk.
User Action Required
If you hold NFTs or tokens from projects deployed using ThirdWeb’s pre-built contracts, take immediate action. Check whether the project team has applied the mitigation patch. Use revoke.cash to review and revoke any unnecessary token approvals on your wallet. Follow the project’s official channels for updates on contract migration or patching. Consider using a hardware wallet for high-value assets as an additional layer of protection against approval-based attacks.
Disclaimer: This article is for informational purposes only and does not constitute financial or investment advice. Always conduct your own research before making any financial decisions.
ERC-2771 and Multicall together was always a footgun waiting to happen. The meta-transaction spec literally trusts a forwarded address without二次验证, combine that with batching and of course you get impersonation
the meta transaction spec trusting a forwarded address was always fragile. combining it with Multicall just made the attack obvious
70k developers using these templates. how many deployed contracts are actually affected though? the article doesn’t give a number and that’s the one that matters
^ right, thirdweb said they contacted projects directly but we still dont know the blast radius. some of those NFT drops had millions in volume
the fact that thirdweb reached out privately before disclosing publicly means some projects probably had no idea they were vulnerable. scary
Mei Lin thirdweb gave projects a 2 week private window to patch deployed mainnet contracts holding real user funds. thats not responsible disclosure, thats negligence dressed up as coordination
Mei Lin 2 weeks private window for contracts already holding user funds is negligent. ThirdWeb should have negotiated 30 days minimum before going public
the private disclosure window was like 2 weeks. for contracts already deployed on mainnet with user funds that is nowhere near enough time
thirdweb said potentially affected but never gave a number. some estimates put it at thousands of deployed contracts across mainnet and L2s
baselayer_ thousands of contracts across mainnet and L2s and thirdweb still said potentially affected. just tell people the number. the vagueness made it worse
This is why I never use pre-built contract templates without reading every line. Composability bugs are the hardest to catch in audit.
ERC-2771 trusting _msgSender() without re-validation when combined with Multicall is such a classic composability trap. two correct specs that are wrong together
this is why protocol composability is a double edged sword. each component in isolation is correct but the interaction surface explodes combinatorially
Olga N. composability is the killer. two individually audited contracts that are perfectly safe alone can be dangerous together. standard audits dont catch interaction surfaces
70k developers using these templates and zero visibility on how many contracts were actually exploitable. the blast radius number is the only metric that mattered and thirdweb never shared it
ERC-2771 trusting _msgSender() without re-validation was always going to break eventually. you cant batch meta-transactions and not expect spoofing
two correct specs creating a critical exploit together is why composability scares me. everyone celebrates lego bricks until two of them snap each other
70K developers using these templates means the blast radius was enormous. thirdweb still never disclosed how many contracts were actually drained
ERC-2771 plus Multicall creating msg.sender spoofing is the kind of composability bug that only shows up when you stack two standards nobody tested together. 70K developers using this template
ERC-2771 trusting _msgSender() without revalidation combined with Multicall batching. two correct specs that create a critical exploit together. composability is terrifying
meta_tx_rat_ standard audits check contracts individually. nobody tests the interaction surface between ERC-2771 and Multicall because each one alone is fine
Sun-hee C. nobody tests interaction surfaces because audit tools check contracts in isolation. Slither and Mythril dont flag cross-standard conflicts. the tooling gap is the real issue here