Today, we have been working closely with @blockaid_ on a detailed investigation into the vulnerability attack on the @humafinance v1 protocol that occurred last night. Blockaid's incident analysis report is very detailed (link in the first reply), so we won't repeat it here.
Below is the event TL;DR and the lessons we learned regarding system architecture and operations. 👇
TL;DR
Attack Incident: The attacker discovered a vulnerability in the smart contract and stole approximately $101,000 in protocol fees and pool owner fees from three old v1 pools on Polygon.
User Funds: User funds were not affected.
Risk Isolation: The issue lies in the Huma EVM v1 contract. It is completely unrelated to PST and all Huma smart contracts on Solana.
Solana Contract: The Solana application uses a completely redesigned architecture and does not contain the logic that was compromised.
Current Status: All v1 pools are suspended.
Key lessons learned: On the surface, this appears to be a smart contract vulnerability in version v1, released in early 2023, but it highlights several issues in protocol design and operation:
1. Don't mix important state transitions with functions containing complex logic. `_updateDueInfo()` and `_getDueInfo()`, which calculate due payments and various fees, were the most complex parts of the v1 contract. Embedding borrower state transitions into these complex functions was not a wise choice. We were later dissatisfied with this design and abandoned it in the Huma v2 smart contract design, adopting a simpler architecture.
2. Resolutely eliminate unnecessary functionality. `requestCredit()` was introduced to support future expansion, but it was never used in actual operation. Non-critical functions naturally receive less testing and security review, creating unnecessary attack surfaces. We discussed removing it before release, but at the time, we thought it wouldn't cause any major problems and kept it. If a function isn't necessary, it shouldn't be included in the contract.
3. Proactively shut down unused pools. Retaining old pools that are no longer needed creates unnecessary risks. Today, both developers and attackers are actively using AI, and some older contracts, not audited by AI, may have more vulnerabilities. The work of shutting down the v1 liquidity pool has been underway, but it wasn't given the highest priority; we should be more decisive on this point.
This is a painful lesson. We should learn from it to avoid wasting this valuable experience. We are sharing our initial reflections and lessons learned here, hoping to help other builders in the ecosystem, especially projects with older contracts, to more effectively improve their defenses against hackers. DeFi United, DeFi Strong! 🛡️
