Cetus Security Issue Insights: What Should DeFi Teams Be Aware Of?

Teams with purely technical backgrounds severely lack basic "financial risk awareness."

Written by: Haotian

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

The report uses a large amount of space to explain the checked\_shlw function of the integer-mate library that checks for errors (should be ≤2^192, actually ≤2^256), and qualifies this as a "semantic misunderstanding." While this statement is technically valid, it cleverly shifts the focus onto 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 1 token can obtain a sky-high liquidity share?

Analyzing the hacker's attack path reveals that for a perfect attack, the hacker must meet four conditions simultaneously: incorrect overflow checks, large bit shifting operations, rounding up rules, and a lack of economically rational verification.

Cetus has been "careless" with every "trigger" condition, for example: accepting astronomical numbers like 2^200 from user input, using extremely dangerous large displacement operations, completely trusting the checking mechanism of external libraries, and most deadly of all - when the system calculated an absurd result of "1 token for a sky-high 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 the universal external library not properly tested for security? Although the integer-mate library has characteristics such as being open-source, popular, and widely used, Cetus used it to manage hundreds of millions of dollars in assets without fully understanding where the security boundaries of this library lie, and whether there are suitable alternatives if the library fails. Clearly, Cetus lacks the most basic awareness of supply chain security protection.

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

When the system allows the input of astronomically large numbers carefully constructed by attackers, the team clearly has not considered whether such liquidity demand is reasonable. Even the largest hedge funds in the world would not require such exaggerated liquidity shares. Clearly, the Cetus team lacks risk management talent with financial intuition.

3. Why were issues still not discovered in advance after multiple rounds of security audits? This statement inadvertently exposes a fatal cognitive bias: the project team outsourced security responsibility to security companies and treated audits as a get-out-of-jail-free card. But the reality is harsh: security audit engineers are good at identifying code bugs; who would think to test for possibly incorrect exchange ratios that sound like a fantasy?

The verification that crosses the boundaries of mathematics, cryptography, and economics is precisely the biggest blind spot in modern DeFi security. Audit firms would say, "This is a design flaw in the economic model, not a code logic issue"; project parties complain, "The audit didn't find 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 seriously lack a basic "financial risk sense."

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

Instead of just focusing on the technical deficiencies related to this hacking attack, I believe that starting from Cetus, all DeFi teams should overcome the limitations of pure technical thinking and truly cultivate the security risk awareness of "financial engineers."

For example: Introduce financial risk control experts to fill the knowledge gaps in the technical team; implement a multi-party audit review mechanism that not only looks at code audits but also includes necessary economic model audits; cultivate a "financial sense," simulate various attack scenarios and corresponding response measures, and remain sensitive to abnormal operations at all times, etc.

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

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

Audit firms can only ensure that the code is free of bugs, 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 boundaries. (The root cause of many "blame-shifting incidents" where security audits were followed by hacker attacks lies fundamentally in this.)

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