News
The Dormant Hijacker - CPIMP Attack
Feb 9, 2026
Anatomy of the Clandestine Proxy-in-the-Middle (CPIMP) Attack
The Clandestine Proxy-in-the-Middle of Proxy (CPIMP) attack is a severe vulnerability in DeFi. Unlike exploits that target logic errors within the code, CPIMP attacks target the deployment sequence itself. It allows an attacker to intercept a protocol during its instantiation, maintaining silent control over the contract storage while the application appears to function normally.
Technical Architecture
To understand the attack surface, we must first understand the EVM architecture regarding upgradability.
Smart contracts are immutable by design. To enable flexible upgrades, developers utilize the Proxy Pattern. The architecture separates the system into two distinct components:
The Proxy Contract (“Front Layer)
The contract holds the state (balances, variables, and owner data). It is the persistent address users interact with.
The Implementation (“Logic/Back” Layer)
This contract contains the executable code.
The Proxy utilizes the EVM opcode delegatecall. The instruction allows the Proxy to execute code from the Implementation contract within the context of the Proxy. In other words, the Implementation contract defines how data changes, but the Proxy is where the users interact with the protocol.
Non-Atomic Initialization
A standard Solidity contract uses a constructor to define its initial state (such as ownership, etc.) at the moment of deployment. Constructors are atomic, which means that the contract cannot exist without them completing.
However, Proxy contracts often cannot utilize constructor(s) for the Implementation logic due to the mechanics of delegatecall. Instead, they rely on a separate public function, typically named initialize().
This separation creates a time interval.
Step 1
The Proxy is deployed. It exists onchain but is uninitialized and has no owner.
Step 2
The developer sends a transaction to call initialize().
Between Step 1 and 2, the contract will accept the first caller of initialize() as its owner.
The Attacker Will Perform Mempool Front-Running
The CPIMP attack exploits this initialization gap.
The attacker utilizes bots to monitor the mempool for pending transactions attempting to initialize a newly deployed Proxy.
Upon detecting the developer's initialization transaction, the attacker broadcasts an identical transaction but with a significantly higher gas fee.
Network validators process the transaction with the higher fee first. The attacker’s transaction initializes the Proxy, establishing the attacker as the owner. This is called front running.
Instead of pointing the Proxy to the legitimate Implementation contract, the attacker points it to his own malicious middleman contract.
It will remain dormant until the time comes
The malicious middleman is designed to be invisible. It will remain dormant in between the contracts.
When a user interacts with the protocol:
The Proxy delegatecalls the Middleware.
The Middleware records sensitive data or checks for specific trigger conditions (such as Total Value Locked, etc.).
The Middleware forwards the call to the legitimate Implementation contract.
The legitimate logic executes, and the correct result is returned to the user.
To the developer and the user, the application will operate as intended. However, the attacker maintains control over the storage slots and can intervene at any time.
Visualizing the Call Stack
Invisible To Code-Level Audits
Because the vulnerability exists in the deployment history rather than the code, standard code audits often fail to detect a CPIMP attack. The protocol may pass all logic checks while the storage ownership remains compromised.
A notable example occurred in December 2025 with the US Permissionless Dollar (USPD). Attackers front-ran the initialization and waited months for the protocol to accumulate liquidity before executing a function in the middleware to drain the funds.
How Shepherd Detects This
This is where Shepherd comes in.
We verify that deployments match intent. After a proxy is deployed, Shepherd reads the EIP-1967 implementation/admin slots and compares them to an expected deployment manifest. These are the implementation you meant to point to, and the upgrader you meant to set.
If any deviation is detected, Shepherd flags it before meaningful funds flow and can replay the situation on a fork to show the concrete impact.
Shepherd helps you stay secure at scale, giving you more confidence in your deployments.