Review of the Conflux Network V2.5 Security Upgrade

Dear Conflux Community Members and Ecosystem Partners,

Recently, the Conflux ecosystem team, GraFun, reported a vulnerability in the Conflux EVM. After investigation and resolution, Conflux successfully completed the V2.5 version security upgrade on March 17, 2025. We are now disclosing the details of this security incident and the handling process as follows.


Background of the Incident

On February 13, 2025, the GraFun team reported a critical vulnerability related to the behavior of the CREATE2 opcode in the Conflux Network:

In the standard Ethereum Virtual Machine (EVM), the CREATE2 opcode fails to deploy a contract if the target address already has a deployed contract, returning a null address. However, the previous implementation of Conflux allowed CREATE2 to redeploy contracts at an address with an existing contract, resetting the contract state to its initial deployment state.

Upon receiving the report, we immediately reproduced and located the vulnerability in the code.


Security Impact Assessment

Within a week of confirming the vulnerability, we conducted an in-depth security impact analysis:

  • Most factory contracts using CREATE2 (e.g., Swappi factories) implemented additional address conflict checks, making them unaffected by this vulnerability.
  • However, Gnosis Safe did not implement such checks and was impacted. An attacker could exploit this vulnerability to reset the state of a Gnosis Safe contract to its initial deployment state. While this did not allow direct tampering with signature permissions, it enabled the replay of previously signed transactions.
  • To further assess the security risks to Gnosis Safe contracts on Conflux, we used the eth_getLogs method to collect all Gnosis Safe contracts and their execution records (approximately 30 contracts) and manually analyzed their security implications. The analysis revealed that most Gnosis Safe fund transfers only involved trusted addresses, with only a small number of funds potentially at risk.

Security Response Process

To protect user assets, we promptly notified the affected ecosystem partners and assisted them in safely transferring potentially at-risk assets. At the same time, we initiated the planned security upgrade process:

  • Vulnerability Fix and Integration Testing (February 21): Completed code fixes and passed integration testing.
  • Internal Testnet Upgrade (February 24): Validated the fix on the internal developer testnet.
  • Public Testnet Upgrade (Announced February 25, Effective March 3): Conducted full testing and security verification on the public testnet.
  • Mainnet Upgrade Deployment (Announced March 3, Effective March 17): Completed the Conflux mainnet security upgrade, fully resolving the vulnerability.

Postmortem Analysis

After resolving the issue, we conducted a thorough analysis of the root causes. The Conflux EVM implementation was initially ported from the OpenEthereum project, which had poor code quality and included two misleading aspects:

  • The function for creating new contracts (new_contract) contained a misleading comment that incorrectly suggested allowing redeployment on addresses with existing contracts. This comment was written before the introduction of EIP-684 (which prohibits address redeployment) and was never updated until OpenEthereum was deprecated. Code Reference
  • OpenEthereum did not define a clear error type, such as “ConflictAddress,” for address conflicts, instead returning an “OutOfGas” error. This made it difficult for developers to recognize the existing logic that prevented redeployment. Code Reference

Misled by these factors, the Conflux team mistakenly believed that Ethereum allowed CREATE2 address redeployment. This misunderstanding was reflected in Appendix A of the Conflux yellow paper and other documentation, which incorrectly described Ethereum as not prohibiting redeployment. Consequently, when introducing Conflux eSpace, we removed the critical check to align with Ethereum’s perceived behavior.

During this process, the Conflux team failed to fully recognize the potential security impact of EVM behaviors, and we bear undeniable responsibility for this vulnerability.


Bug Bounty Reward

Given the critical importance of CREATE2 in the EVM and the potential severity of this vulnerability, we rated it as “Critical” and awarded the GraFun team a base bounty of 50,000 CFX. Additionally, considering their timely report helped prevent potential losses, we issued an additional reward of 10,000 CFX, bringing the total to 60,000 CFX.


Follow-Up Actions and Security Enhancements

As Conflux advances its PayFi strategy, financial applications demand higher security and maturity for ecosystem tools. To strengthen the security of Conflux ecosystem tools and leverage mature Ethereum products, we plan to synchronize most Ethereum EVM features during the next hard fork upgrade (see CIP-645). Additionally, we will integrate Ethereum’s official EVM specification test cases into Conflux to enhance compatibility with the Ethereum ecosystem and prevent similar security issues in the future.

We sincerely thank the community and ecosystem partners for their continued support and attention. The Conflux team remains committed to transparency, rapid response, and safeguarding ecosystem security and user interests.

Conflux Team

March 24, 2025