RedSonic Vault was attacked by Ethereum lightning loan, stealing 9.25 ETH

TLDR: The beginning and end of the RedSonic Vault exploit incident

RedSonic Vault vulnerability exposes dual asset pricing flaw

RedSonic Vault lost 9.25 ETH due to an attacker exploiting dual asset pricing vulnerability. The core of the vulnerability lies in an unrestricted registerErc20 function that allows attackers to add a second conflicting stETH share category. The attacker borrowed 1,139 WETH through Balancer to conduct a lightning loan operation without having to invest any own start-up funds. Security company ExVulSec tracked and published the complete exploit process, including redemption and final loan repayment steps on Curve.

How does exploit unfold?

A lightning loan attacker withdrew 9.25 ETH from Ethereum's RedSonic Vault in a single transaction. Blockchain security company ExVulSec identified the exploit and released a detailed technical analysis. The attacker manipulated an unlimited asset registration feature, causing the same underlying collateral to be counted twice. On-chain records show that the entire operation was completed in a self-contained transaction.

The attacker borrowed 1,139 WETH from Balancer Lightning to fund the entire operation without requiring any upfront ownership capital. RedSonic's vault prices its rsvETH shares through a function called `getTotalAssetBalance`. For Lido positions, this function directly reads the original stETH balance of the vault. This design choice became the basis for exploit: When the balance changes unexpectedly, the price of the shares linked to the original balance may change without the corresponding shares being minted or destroyed.

According to ExVulSec, the vault's registerErc20 function does not have any access restrictions. Anyone can register a new asset class in the vault. The attacker registered stETH as a second asset and created a category called rsvstETH. Both share types then derive value from the exact same underlying stETH balance.

After execution is completed, the vulnerability contract self-destroys. Security researchers point out that self-destroying contracts often add to the complexity of subsequent chain tracing. Flash loans allow borrowers to obtain large amounts of money without mortgaging any assets, provided the loan is repaid within the same transaction. Attackers often use this mechanism to fund exploits that otherwise require large amounts of capital.

Alert-Ethereum @reddio_com
RedSonic Vault was stolen approximately 9.25 ETH. A zero-capital attacker borrowed 1,139 WETH from Balancer in a flash, pushing up the price of his treasury share and cashing out. This exploit runs within the constructor of a self-destroying contract.
Root cause: ...

RedSonic Vault vulnerability exposes dual asset flaw

The attacker first deposited 1,130 ETH, gaining nearly 99% of almost all uncirculated rsvETH shares. This position laid the foundation for subsequent exploits.

Next, the attacker directly deposited 9.34 stETH into the vault. This single deposit increased the stETH balance but did not create any new rsvETH shares. Since the pricing of rsvETH reads the original stETH balance, additional depositors artificially push up the share price. As a result, the value of the attacker's existing rsvETH position increased instantly without issuing any new rsvETH.

According to ExVulSec's transaction analysis, the attacker then redeemed rsvETH in exchange for 1,139.5 ETH. This single redemption operation generated the entire profit of 9.25 ETH.

The same attacker also redeemed rsvstETH shares separately to obtain stETH. The same underlying collateral was actually paid twice from the same shared pooled treasury balance.

ExVulSec reported that recycled stETH was exchanged for ETH on Curve. The attacker repaid Balancer's lightning loan in the same deal.

Etherscan data shows that the attacker's wallet address is `0x70f2333d21Ed7E7D105 F6578227 A9A747687982 C`. The RedSonic Vault contract itself is located at `0x4315990d9eeaffdfafd 49958b4851f203fa1126f`. The hash value of the attack transaction is `0xe3cba 90e865c6cba950 ebce36a52607 f51f1 fd33 cd9 fb920c78803f19b57791a`. The transaction is publicly visible on Etherscan, allowing anyone to verify the details of the exploit.