Anatomy of a Hack: How Design Decisions Led to the USPD Exploit

The CPIMP attack on USPD happened because of specific design choices we made. Here is how we got there, what we learned, and what we are changing for V2.

The Decision: Deterministic Addresses Across All Chains

Early in 2025, when we started building USPD, we decided to deploy all contracts to the same address on every EVM chain using CREATE2.

The benefits seemed clear:

• Simplified UX: Users interact with the same addresses regardless of chain.
• Easier integrations: Partners only need to whitelist one set of addresses.
• Cross-chain consistency: Documentation and tooling work universally.
• Scam prevention: One canonical address helps users spot fakes on other chains.

This decision alone is not problematic. Many protocols use CREATE2. The complexity came from how our contracts interact with each other.

The Problem: Circular Dependencies

Our architecture has multiple contracts that need to know about each other during deployment. Looking at our deployment script (04-DeploySystemCore.s.sol), the dependency graph is messy:

┌─────────────────┐     ┌─────────────────┐     ┌─────────────────┐
│  StabilizerNFT  │────▶│   cUSPDToken    │────▶│    USPDToken    │
└─────────────────┘     └─────────────────┘     └─────────────────┘
        │                       │                       │
        │                       ▼                       │
        │               ┌─────────────────┐             │
        │               │  RateContract   │◀────────────┘
        │               └─────────────────┘
        │                       ▲
        ▼                       │
┌─────────────────┐             │
│    Reporter     │─────────────┘
└─────────────────┘
        ▲
        │
┌─────────────────┐
│  StabilizerNFT  │ (circular!)
└─────────────────┘

Here is what each contract needs at initialization:

StabilizerNFT needs Reporter. Reporter needs StabilizerNFT.

Also, cUSPDToken needs the StabilizerNFT address, but StabilizerNFT needs cUSPDToken to be deployed first so it can be passed during initialization.

Why Not Just Use Setter Functions?

Why not deploy contracts with placeholder addresses and update them via setter functions afterward?

We considered this, but we had reasons to use immutable arguments:

1. Contract Size Limits: Our StabilizerNFT was close to the 24KB limit. Every setter function adds bytecode. We could not afford multiple setters.

2. Immutability as Security: We wanted contracts to be immutable. When you look at a deployment, you should see exactly what it is configured to do. No hidden admin functions to change critical addresses later.

3. Minimizing Upgrade Surface: We wanted to deploy, verify, and revoke upgrade capabilities. Setter functions require keeping admin keys active longer.

4. Audit Scope: Every setter function is an attack surface. Auditors need to verify access controls and reentrancy for functionality we would only use once.

The “Solution”: Deploy Proxy First, Initialize Later

To fix the circular dependency while keeping addresses deterministic, we used a specific pattern:

1. Deploy the StabilizerNFT implementation (no dependencies needed).
2. Deploy the StabilizerNFT proxy pointing to the implementation, but do not initialize it yet.
3. Deploy cUSPDToken (can now reference the proxy address).
4. Deploy USPDToken (references cUSPDToken).
5. Deploy Reporter (references the proxy address and cUSPDToken).
6. Deploy InsuranceEscrow (references the proxy address).
7. Now initialize the StabilizerNFT proxy with all the addresses.

This is in our deployment script:

function run() public {
    vm.startBroadcast();
 
    deployStabilizerNFTImplementation();
    deployStabilizerNFTProxy_NoInit(); // <- THE FATAL STEP
    deployCUSPDToken();
    deployUspdToken();
    deployReporterImplementation();
    deployReporterProxy();
    deployInsuranceEscrow();
    initializeStabilizerNFTProxy(); // <- Initialization happens later
    setupSystemRoles();
 
    saveDeploymentInfo();
 
    vm.stopBroadcast();
}

The gap between deployStabilizerNFTProxy_NoInit() and initializeStabilizerNFTProxy() is where the attacker struck.

We did not know about the CPIMP vulnerability. We thought if someone front-ran our initialization, we would see it. The transaction would fail or behave unexpectedly, and we would redeploy. It did not look like that happened when we deployed. Everything appeared normal. We continued operating on the proxy with the shim installed.

The Attack: A Sandwich

This was not a simple shim installation with a generic initialize() call.

Block-by-Block Timeline

The attacker inserted their transaction one block after our proxy deployment and two blocks before our initialization.

Not a Generic Attack

Our initialize function takes 10 parameters:

function initialize(
    address _cuspdToken,
    address _stETH,
    address _lido,
    address _rateContract,
    address _reporterAddress,
    address _insuranceEscrowAddress,
    string memory _baseURI,
    address _stabilizerEscrowImpl,
    address _positionEscrowImpl,
    address _admin
)

The selector is 0xd9230389. It is not the standard initialize() or initialize(address).

The attacker could not simply listen for generic initialize calls. They had to:

1. Detect our proxy deployment.
2. Analyze the implementation contract to find the initialization function.
3. Determine the correct function signature and parameter types.
4. Craft valid parameters.
5. Package everything into a Multicall3 transaction.
6. Submit it before our initialization landed.

They had about 11 seconds to do this.

Using Our Own Implementation Against Us

The attacker called our legitimate implementation’s initialize function with substituted parameters. The execution flowed through our own contract code.

At the end, the attacker:

1. Set their own storage variables for the CPIMP shim.
2. Reset the _initialized flag back to 0.

This last step is crucial. When our actual initialization transaction landed two blocks later, it succeeded without reverting. The proxy appeared to initialize normally. We had no indication anything was wrong.

The Shim: A Masterpiece of Stealth

We analyzed the attacker’s shim (0xAC075b9bf166e5154Cc98F62EE7b94E5345Cc090). It aligns with findings by pcaversaccio and Dedaub. It is designed to look like a legitimate upgradeable proxy while secretly maintaining a “Shadow Administration” layer.

The “Shadow Admin” Mechanism

The shim hardcodes a secret administrator address that bypasses all onlyOwner checks:

// In multiple functions (e.g., 0x9441e515, 0x8c84497d)
address owner = stor_f364...00; // Reads from hidden slot
if (msg.sender == owner) {
    // BYPASS: Grants full access
} else {
    // Fake check to make it look legitimate or delegate to real impl
}

The “Trojan Horse” Storage Layout

The shim maintains two parallel implementation pointers:

1. Public Implementation (0x3608...): Derived from bytes32(uint256(keccak256('eip1967.proxy.implementation')) - 1). Points to the Shim itself (or a fake benign contract) so block explorers show “Verified Source.”
2. Shadow Implementation (0x7050...): Derived from keccak256("org.zeppelinos.proxy.implementation"). Points to the Real Malicious Logic (or your original logic when they want to hide).

The shim decides which one to use based on the function selector:

// In function 0x30e3 (Fallback/Delegate logic)
if (selector == 0x4f1ef286) { // upgradeToAndCall
    // Hijack the upgrade process
} else {
    // Delegate to the shadow implementation
    delegatecall(stor_7050...); 
}

When you call the contract, it works. When they call it, they hit their backdoors.

Why Counter-Attacks Are Nearly Impossible

We looked at surgically removing this shim without abandoning the proxy address. It is risky because the shim intercepts upgradeToAndCall.

The Problem: Interception

If you call upgradeToAndCall(newImpl, data), the Shim’s logic at 0x4f1ef286 executes:

• It checks msg.sender == admin (which might be you, OR it might be overridden to be the attacker).
• Even if it allows the upgrade, the Shim often only updates the “Public” implementation slot while keeping the “Shadow” implementation active.
• It might block upgrades unless they come from the attacker.

The “Storage Nuke” Strategy

To reclaim the proxy, you must bypass the Shim’s logic entirely or trick it into overwriting its own brain. Since you cannot bypass the code execution, you must find a path that allows arbitrary storage writes.

Why Automated Detection Is Hard

These shim contracts are hard to find automatically. You cannot reliably search for specific storage slot patterns because the attacker can change them.

The storage slots we identified (STOR_FF36_OPERATOR, STOR_10F3_LEGIT_IMPL) are just the ones this attacker used. Tomorrow, they could deploy a new shim with different slots and logic. Any automated detection tool built today will be obsolete when the attacker adapts.

The Scale Question: Targeted or Automated?

We scanned for state diffs from mainnet from block 21047124 and marked infected contracts.

Key findings:

• First CPIMP infection: Block 21864585 on 2025-02-17 07:22:59 UTC from 0x00bda7096754410b9caa2b559fb263cda1b1b243.
• Last infection: Infections are still occurring.
• Total infections found: ~200 proxies.
• Infections after our deployment: ~30.

We also searched for proxies deployed uninitialized that were later initialized. Even same-block transactions got bundled together. From the 208 infected proxies we found, this occurred in 94 cases - about 50% of them.

The sophistication required suggests this is not a casual operation. This is infrastructure built for scale, likely part of a larger MEV/searcher operation. Our sandwich attack specifically came via BuilderNet as far as we can tell.

We do not have data on how many other protocols have been compromised. The CPIMP attack is designed to be invisible until exploitation. This attack targets the trust developers place in their deployment scripts. It exploits the assumption that a few seconds between transactions is safe.

We were one of ~200 victims. We will not be the last.

Why We Didn’t Catch It

The Attack Vector Was Unknown To Us

When we wrote this deployment script in early 2025, we did not know about CPIMP. The attack was first publicly disclosed by pcaversaccio on X/Twitter in July 2025  - months after our architecture was finalized.

Our final security audits were completed on August 20, 2025. Neither we nor our auditors (Nethermind and Resonance) were aware of this vulnerability. The disclosure in July mitigated a large-scale attack before it caused damage, so there was no media outcry. It never reached us.

We deployed on September 16, 2025. The attacker sandwiched our initialization.

We Were Busy Building

Between audit completion and deployment, we were:

• Finalizing contract changes.
• Building the frontend.
• Marketing.
• Preparing documentation.

The CPIMP attack generated little noise in the security community because the mitigation was successful. We were not monitoring security Twitter 24/7. We were building.

Some say we should have had dedicated security personnel. But this vector was not widely known, even among professionals. It is a supply-chain attack that bypasses traditional audit scopes.

Everything Looked Right

After deployment, we checked:

• ✅ All transactions succeeded.
• ✅ Etherscan showed our legitimate implementation.
• ✅ All contract functions worked.
• ✅ Our initialization transaction completed successfully.
• ✅ Nobody seemed to have front-run us.

The CPIMP attack is designed to be invisible. The attacker’s contract forwards all calls to the legitimate implementation. There were no visible signs of compromise.

Addressing the “Inside Job” Narrative

We have seen speculation that this was an inside job. The timing seems perfect and the attack sophisticated.

Here is what we know:

• The attacker’s infrastructure has infected ~200 proxies across the ecosystem.
• The attack pattern is consistent across all victims.
• The attacker waited nearly three months before draining funds. This suggests automated monitoring rather than insider knowledge.
• Our upgrade attempt on December 4th likely triggered their monitoring systems. They drained within minutes.

This was not someone with insider access. This was industrial-scale infrastructure designed to exploit uninitialized proxies. We ended up using this pattern because it solved our specific architectural constraints at the time. So did ~199 other contracts.

The attacker is not targeting USPD specifically. They are targeting every team that deploys an uninitialized proxy.

The Trigger: A Routine Upgrade

For nearly three months, the infected contracts operated normally. Users minted USPD, stabilizers deposited collateral, yield accrued.

On December 4th, 2025, we attempted a routine upgrade to fix a minor bug in the StabilizerNFT. This likely triggered the attacker’s monitoring systems.

The execution of the attack happened in three steps:

1. Deployment of Intermediary: The attacker deployed a contract at 0x77b2a9261D53e4F001b6F821f6beA003a31b3484 (Tx: 0x02f3cf5bc9bfdf02e38febe947e323d8eb2a275920e1980719a966ac8923c799).
2. Deployment of Malicious Logic: They deployed a modified version of our StabilizerNFT at 0xa3D2616Ee942b36648eaA55976eE7B761bd2a21B (Tx: 0x6a748155bb97e5d25626173593060ee2f6bc76174541e5b1ef9690f8d895e9f2). This contract seems to have been hastily crafted: decompilation shows it still contains our original overcollateralization checks, just modified to allow the withdrawal.
3. The Drain: In transaction 0xa7cab072bf0453301a0ab1b06c49a9405d115824fc617fb42cba9b70f3b893c2, they called upgradeAndCall. This updated the implementation to 0x77b..., which then called upgradeAndCall on the StabilizerNFT to switch to the malicious 0xa3D... logic. This logic executed the drain to 0x083379bdac3e138cb0c7210e0282fbc466a3215a.

Initially, we thought we introduced a bug during the upgrade. It was only through forensic analysis that we discovered the attacker had been “super admin” since the first block of the proxy’s existence.

What Other Teams Can Learn

We are sharing this because we do not want other teams to make the same mistakes.

1. Never Deploy Uninitialized Proxies

If you must use the deploy-then-initialize pattern, do it in a single atomic transaction. Use a deployer contract that:

• Deploys the proxy.
• Immediately initializes it.
• All in one transaction that either fully succeeds or fully reverts.

// BAD: Two separate transactions
proxy = deployProxy(implementation);
// ... attacker can front-run here ...
proxy.initialize(params);
 
// GOOD: Single atomic transaction
proxy = deployAndInitialize(implementation, initParams);

2. Own Your Stack Trace

Do not just check that your transaction succeeded. Understand everything that happened. After any deployment:

• Trace the full execution path.
• Verify every storage slot that was written.
• Check that no unexpected contracts were called.

This is tedious. It is also the only way to catch sophisticated attacks. Block explorers and “transaction succeeded” messages tell you nothing about what actually happened under the hood.

3. Never Rely Solely on Audits

We paid for two professional audits. We are grateful for the work Nethermind and Resonance did. But audits are not enough.

4. Stick to Proven Patterns

Our desire for deterministic addresses and immutable configurations added complexity. That complexity created a vulnerability. Deterministic addresses do not help if initialization can be hijacked. Prioritize safe, atomic initialization over address determinism.

5. Stay Connected to Security Research

The CPIMP attack was disclosed ~2 months before we deployed. If we had been plugged into security research channels even more, we might have caught it.

What We Are Doing Differently for V2

USPD V2 will feature:

1. Atomic Deployment: All proxy deployments will include initialization in a single transaction. No gaps.

2. Simplified Dependency Graph: We are redesigning the architecture to minimize circular dependencies. Fewer dependencies means simpler deployment.

3. Modular Contracts: Instead of one large StabilizerNFT, we are breaking functionality into smaller contracts.

4. Manual Verification: We will manually trace and verify every storage slot and execution path after deployment. No automated tools. Human eyes on every transaction.

For details on V2, see our Path Forward post.

Acknowledgments

Thank you to:

pcaversaccio  for the original public disclosure of the CPIMP attack  in July 2025. This research was critical.

SEAL 911  (X/Twitter ) for their immediate response. They helped by:

• Flagging our token at CEXs and DEXs.
• Coordinating with block explorers.
• Pointing us in the right direction.

If you ever experience a security incident, SEAL 911 is an invaluable resource.

A Note on Block Explorer Warnings

In the original Dedaub article  about the CPIMP attack, they mentioned that Etherscan would mark these contracts.

This has not happened yet. The last CPIMP infection we detected was from today, and infected contracts still show misleading implementation information on block explorers. Do not rely on block explorer warnings. Verify storage slots directly.

Closing Thoughts

Every decision we made seemed reasonable at the time.

• Deterministic addresses? Industry best practice.
• Immutable configurations? More secure than setter functions.
• Minimal upgrade surface? Reduces long-term risk.

But combined with an unknown attack vector, these decisions created a vulnerability we could not see.

The hardest part of security is protecting against attacks that do not exist yet. We failed at that. We own it. We are building V2 with that humility.

To the critics: We followed industry standards. We had two professional audits. We tested. We operated with rigor.

To other teams: Learn from our experience. Atomic deployments. Own your stack traces. Never trust - always verify. Do not let this happen to you.

We are not giving up. We are rebuilding.

Further Reading

• Preliminary Postmortem: The CPIMP Attack - Technical details of the attack
• The Path Forward: USPD V2 - Our recovery plan and V2 roadmap
• pcaversaccio’s original CPIMP disclosure  - The tweet that first publicly revealed this attack vector
• Dedaub: The CPIMP Attack  - Original security research
• SEAL 911  - Emergency security response for the ecosystem

If you have questions or want to discuss this further, join us on Discord  or reach out on X .

- The USPD Team

For clarity, this is the data we put together by looking at state diffs from mainnet:

Table truncated for readability. Full data available upon request.