Cetus Security Issues Reminder: What should the DeFi team pay attention to?

Author: Haotian

After reading the security "review" report on the hacking incident of @CetusProtocol, you will find a "thought-provoking" phenomenon: the technical details are disclosed quite transparently, and the emergency response can be considered textbook level, but on the most critical question of "why was it hacked," it seems to avoid the main issue.

The report uses a large amount of space to explain the checked\_shlw function of the integer-mate library for error checking (should be ≤2^192, actually ≤2^256), and qualitatively describes this as a "semantic misunderstanding." Although this description is technically valid, it cleverly shifts the focus toward external responsibility, as if Cetus is also an innocent victim of this technical flaw.

The question arises, since integer-mate is an open-source and widely used mathematical library, how could such an absurd error occur where one token can obtain a huge liquidity share?

Analyzing the hacker attack path reveals that to achieve a perfect attack, hackers must simultaneously meet four conditions: incorrect overflow checks, significant bit shifting operations, rounding up rules, and a lack of economic rationality verification.

Cetus carelessly overlooked every "trigger" condition, for example: accepting user input like 2^200, using extremely dangerous large displacement operations, fully trusting the external library's checking mechanism, and most critically—when the system calculated the absurd result of "1 token for an exorbitant share," it executed it directly without any economic sanity checks.

Therefore, the points that Cetus should truly reflect on are as follows:

1. Why was proper security testing not done for the generic external library? Although the integer-mate library has characteristics such as being open-source, popular, and widely used, Cetus used it to manage assets worth hundreds of millions of dollars without fully understanding where the security boundaries of this library are, and whether there are suitable alternatives if the library fails in its function, etc. Clearly, Cetus lacks the most basic awareness of supply chain security protection.

2. Why is it allowed to input astronomical numbers without boundaries? Although DeFi protocols should seek decentralization, the more open a mature financial system is, the more it requires clear boundaries.

When the system allows the input of astronomical numbers carefully crafted by attackers, the team clearly hasn't considered whether such liquidity demands are reasonable. Even the world's largest hedge funds can't possibly require such exaggerated liquidity shares. Clearly, the Cetus team lacks risk management talent with financial intuition.

3. Why were problems still not detected after multiple rounds of security audits? This sentence inadvertently reveals a fatal cognitive bias: the project team outsources security responsibilities to security companies, treating audits as a get-out-of-jail-free card. But the reality is harsh: security audit engineers are skilled at finding code bugs, but who would think to test the exchange ratio, which sounds absurd, to see if something is amiss?

The boundary verification that crosses mathematics, cryptography, and economics is precisely the biggest blind spot in modern DeFi security. Audit firms will say, "This is an economic model design flaw, not a code logic issue"; project teams complain, "The audit did not identify any problems"; while users only know that their money is gone!

You see, this ultimately exposes the systemic security shortcomings of the DeFi industry: teams with purely technical backgrounds severely lack the basic "financial risk sensitivity."

From the report by Cetus, it is clear that the team has not reflected adequately.

Compared to the purely technical shortcomings regarding this hacker attack, I believe that starting from Cetus, all DeFi teams should move away from the limitations of pure technical thinking and truly cultivate the safety risk awareness of "financial engineers."

For example: bring in financial risk control experts to fill the knowledge gaps in the technical team; establish a multi-party audit review mechanism that not only examines code audits but also incorporates necessary economic model audits; cultivate a "financial sense" by simulating various attack scenarios and corresponding response measures, and maintain sensitivity to abnormal operations at all times, etc.

This reminds me of my previous experience working in security companies, including the consensus among industry security leaders like @evilcos, @chiachih_wu, @yajinzhou, and @mikelee205 during our discussions.

As the industry matures, technical bugs at the code level will gradually decrease, while the "awareness bugs" in business logic, where boundaries are unclear and responsibilities are ambiguous, will become the biggest challenge.

Audit companies can only ensure that the code is bug-free, but how to achieve "logical boundaries" requires the project team to have a deeper understanding of the essence of the business and the ability to control the boundaries. (This is the root cause of many previous "dumping incidents" that were still attacked by hackers after security audits)

The future of DeFi belongs to teams with strong coding skills and a deep understanding of business logic!