In December 2025, Aevo, formerly known as Ribbon Finance, was the victim of a roughly $2.7 million hack. The attacker exploited vulnerabilities within the project’s smart contracts to allow the attacker to receive payouts from the vaults.
Inside the Attack
The root cause of the attack was a combination of weak access control and precision errors. Six days before the attack, the project rolled out an oracle update that updated its precision to support 18 decimal places, which some newer tokens use. However, some older assets supported by the platform still use eight decimal places, creating a mismatch.
The proxy-based oracle stack used to deploy the updates to the oracle also included an access control vulnerability. It permitted anyone to set expiry prices for newly-created assets on the platform.
The attacker exploited these vulnerabilities by using a malicious smart contract to create options products with an expiry date in the near future. These were designed so that the strike price would be far below the market price for an underlying asset. Additionally, these options used both an 18-decimal and an 8-decimal precision asset, taking advantage of the decimal mismatch.
For example, one involved an stETH call option with a strike price of 3,800 USDC (8-decimal) collateralized with WETH (18-decimal) and created oTokens from these. When this expired on December 12, the system realized that the current value of stETH was higher than the 3,800 USDC, and the attacker burned 225 oTokens to drain about 22.46 WETH in this instance.
The attacker created three accounts to exploit the vulnerabilities, all marked as type 0 (fully collateralized) with minimal collateral. They were able to mint a large number of oTokens with this collateral, and the lack of maximum payouts per account or option series allowed the attacker to drain the $2.7 million from the protocol.
Lessons Learned from the Attack
The Aevo hack was made possible by an update to the project’s oracle that introduced two issues: the decimal mismatch and access control issues. The attacker exploited both of these errors, allowing them to drain significant value from the protocol.
This issue demonstrates the importance of thorough testing of smart contract code before deployment on-chain. While the decimal update was designed to support newer protocols already using 18-decimal precision, it didn’t consider the potential impacts on older projects with only eight decimal places.
Halborn offers comprehensive smart contract security audits designed to identify both vulnerabilities and logical errors in smart contract code. Get in touch to find out more.