Often, security efforts in the DeFi space focus on smart contract vulnerabilities or off-chain threats. However, while smart contract audits and private key security are important components of a DeFi security program, they’re not enough for security.

Clandestine Proxy-in-the-Middle of Proxy (CPIMP) attacks exploit vulnerabilities in the smart contract deployment process. They exploit the use of upgradeable proxies in smart contracts to allow an attacker to silently gain control over a project.

Proxies are a common feature within DeFi projects. Blockchains’ digital ledgers are famously immutable, and smart contracts are recorded on this ledger. This means that, once a smart contract has been deployed on-chain, it can’t be changed, which is a major problem for feature and security updates. By default, updates would require deploying an entirely new smart contract and pointing all users, frontends, etc., to the new address.

This is where a proxy contract comes into the picture. A proxy contract acts as a static point of contact for the project. It stores the address of another smart contract, which encodes all of the project’s logic, and forwards all requests to it using delegatecall. This way, logic can be updated by deploying a new smart contract and updating the address stored by the proxy contract. Since the proxy’s address doesn’t change, this means that no one needs to update their code to follow the change.

When deploying a project with an upgradeable proxy, a project needs to deploy both contracts on-chain, set the implementation address for the proxy, and define any required admin roles within the proxy. If not done correctly, this can introduce a vulnerability for an attacker to exploit.

A CPIMP attack is a front-running attack targeting a project with a new upgradeable proxy contract. Attackers look for proxy contracts that are deployed without the target address or admins specified.

If this is the case, then an attacker may have a window to front-run the transaction used to configure these parameters in the proxy. To do so, they would deploy a second proxy pointing to the intended target contract and configure the legitimate proxy to point to their proxy and have them as the administrator.

When the project sends in its implementation transaction, it completes without reverting, making it appear that the implementation is successful. However, the attacker ensures that each transaction completes by putting itself in the implementation slot within the legitimate proxy’s storage space, preventing any upgrades that would remove their control.

The goal of a CPIMP contract is to perform a subtle on-path attack on an upgradeable proxy and its implementation. This includes allowing normal transactions to go through without raising the alarm.

CPIMP contracts accomplish this by inserting themselves between the legitimate proxy and the implementation. The transaction flow is as follows:

• Transaction is submitted to legitimate proxy

• Legitimate proxy delegatecalls the contract specified by its implementation address (CPIMP contract)

• CPIMP contract receives call and executes tailored malicious logic (can edit transaction, block certain actions, etc.)

• CPIMP contract delegatecalls implementation contract

• Implementation contract executes the desired functionality

The deployment of the CPIMP contract between the legitimate proxy and implementation contract gives it a great deal of control while minimizing the risk of exposure. The malicious proxy could choose to forward transactions without any edits or take action to prevent undesirable actions, such as attempts to rescue stored funds or upgrades designed to remove the malicious proxy.

When CPIMP contracts were first discovered in the wild, they were found to be part of a broad, sophisticated attack campaign. Some of the ways that the attacker tailored these contracts to conceal their presence while maintaining control include:

• Implementing backdoors that overrode admins on the legitimate proxy

• Ending each transaction by setting the implementation to the attacker's address

• Implementing logic tailored to a particular project or use case

• Creating anti-recovery mechanisms that block transfers of over 90% of deposited funds

• Support for bulk draining of tokens and ETH

• Hiding from block explorers by placing deceptive implementation addresses at locations specified by an old OpenZeppelin proxy contract standard.

These and other techniques helped conceal the CPIMP proxy while providing it with full control over the target contract. Until the attacker made a big move, such as draining value from a target project, the primary sign of the attack was the fact that two delegatecalls are performed when executing transactions. However, few users perform this type of deep analysis, especially when transactions complete successfully.

In December 2025, the US Permissionless Dollar (USPD), a USD stablecoin, was the victim of a CPIMP attack. Several months earlier, the attacker front-ran the implementation transaction, inserting a malicious proxy and taking control over the contract. In December 2025, the attacker performed an unauthorized mint of the stablecoin, allowing them to drain approximately $1 million from the protocol.

CPIMP attacks are subtle attacks that target the deployment phase of the smart contract lifecycle rather than exploiting vulnerabilities in the code. This means that a smart contract audit of the implementation contract won’t identify the issue. Instead, attackers take advantage of the deployment of uninitialized proxy contracts to insert their own, malicious contracts between the proxy and intended implementation.

To avoid this threat, proxy contracts should never be deployed in an uninitialized state. Instead, projects should perform atomic transactions that both deploy and initialize the contract within the space of a single transaction. This eliminates the opportunity for an attacker to front-run the transaction by ensuring that the deployment and initialization of the proxy contract are completed within the same transaction, succeeding or failing together.

Halborn offers a range of advisory services designed to help DeFi projects protect themselves against CPIMP and other sophisticated attacks. In addition to auditing smart contracts for vulnerabilities and business logic errors, Halborn advisors can also support a project from the early design stages through deployment on-chain. To learn more about how you can protect your project with Halborn, get in touch.