In December 2025, USPD, a stablecoin pegged to the US dollar, was exploited for a bit over 1 million dollars’ worth of assets. What made this incident unusual is that the attacker did not exploit a bug in our audited smart contracts, but a weakness in how we deployed and initialized our proxy contracts on-chain. This article walks through what happened, why it was possible, and what other teams can learn from it.mexc+2
What Actually Happened
USPD was using an upgradeable proxy setup for its core StabilizerNFT contract, which manages collateral and minting logic for the stablecoin. During deployment in September 2025, there was a short window between deploying the proxy and calling its initialize function where the proxy was still uninitialized and therefore “claimable” by anyone who called initialize first.
An attacker was monitoring the mempool for exactly this pattern: newly deployed, uninitialized proxies that match interesting targets. Within a single block of our proxy deployment, they used a Multicall3 transaction to front‑run initialization, successfully calling own initialize function before our deployment script did. That single step gave them administrator‑equivalent control over the proxy from block one, even though everything looked normal to us.
CPIMP: A “Proxy in the Middle of a Proxy”
CPIMP (Clandestine Proxy In the Middle of Proxy) is a sophisticated attack that hijacks uninitialized upgradeable proxy contracts by inserting a malicious “middleman” contract between the proxy and its legitimate implementation.
The attack is particularly dangerous because it is completely transparent to normal protocol operation—users, developers, and even block explorers like Etherscan see the legitimate implementation, while the attacker maintains hidden control.

Timeline of Events
| Date | Event |
|---|---|
| Mid-July 2025 | CPIMP attack vector first detected in the wild by security researchers |
| August 20, 2025 | final security audit completed. No auditing firm informed us about the vulnerability, potentially unaware of this exploit |
| September 16, 2025 | USPD protocol deployed; attacker front-runs initialization and infects our proxy contracts |
| December 4, 2025 | Attacker exploits the infected contracts, draining fund |
How the Attacker Took Over the Proxy
The attacker’s workflow was sophisticated but systematic:
- Detect the deployment
They monitored the network for new proxy deployments that were not immediately initialized, especially from known deployer addresses or patterns. - Analyze our implementation on the fly
Once the implementation address was visible, they could fetch and decompile it (or use preexisting templates) to identify the correct initialize function signature and parameter types. - Front‑run our initialization
Using Multicall3, they constructed a transaction that:- Called our implementation’s initialize with attacker‑chosen parameters.
- Set up their CPIMP shim as the effective implementation.
- Reset the initialization flag so our later initialize call would still succeed.
- Let our initialization succeed
Two blocks later, deployment transaction executed and appeared to “initialize” the proxy as usual. Because the shim had reset the internal initialized flag, call did not revert and all the values we expected were written but beneath that, the shim had already wired itself in.
The Actual Exploit
- Deployed an intermediary contract and a modified version of StabilizerNFT logic.
- Used their hidden upgrade control path to switch the proxy’s implementation to the malicious logic.
- Used that logic to mint about 98 million USPD and withdraw roughly 232 stETH (more than 1 million dollars in value at the time), sending funds to their own addresses and onward through DEXes and privacy tools.
At first glance, this looked like a bug in the new implementation or upgrade. Only after forensic analysis did it become clear that the attacker had been “super admin” since the very first block the proxy existed.
Key Takeaways for Teams
- Audited code ≠ secure system
Deployment and proxy lifecycle are part of the attack surface. - Never leave proxies uninitialized
Deploy and initialize in a single atomic transaction.
Same-block deploy + init is still unsafe. - Avoid over-complex deployment setups
Custom scripts, deterministic addresses, and circular dependencies increase risk. - Treat deployment as a security step
Verify post-deployment traces and storage, not just explorer status. - Assume full attacker automation
If a window exists—even for seconds—it will be exploited.
Reach out to us for high-level smart contract security and assistance.
At Safe Edges, we review not only contract logic but also deployment flows and proxy initialization paths, because most modern exploits happen there.
If you’re using proxies, deterministic addresses, or complex multi-contract systems, treat this incident as a signal to re-evaluate your deployment pipeline. Even the strongest code cannot protect you if the door is left open at the moment it goes on-chain.
- https://www.mexc.co/en-IN/news/231917
- https://www.mexc.com/news/234612
- https://crypto-economy.com/uspd-hack-1m-gone-in-stablecoin-breach/
- https://dedaub.blog
- https://www.mexc.com/en-NG/news/234196
- https://dedaub.com/blog/the-cpimp-attack-an-insanely-far-reaching-vulnerability-successfully-mitigated/
- https://www.tronweekly.com/uspd-protocol-suffers-exploit-through-cpimp-at/
- https://dedaub.com/blog/mass-disclosure-of-griefing-vulnerabilities/
- https://www.cryptotimes.io/2025/12/10/uspd-exploiter-remained-silent-for-78-days-after-proxy-takeover/
- https://dedaub.com/blog/the-11m-cork-protocol-hack-a-critical-lesson-in-uniswap-v4-hook-security/
- https://www.mexc.co/en-IN/news/229683