Reddio RedSonic Vault Exploited for ~9.25 ETH: Cross-Vault Asset Double-Counting Flaw Explained

Overview

On September 5–6, 2026, blockchain security firm issued a threat intelligence alert regarding an exploit on Reddio’s RedSonic Vault. The incident resulted in a loss of approximately 9.25 ETH. The attacker leveraged a cross-vault asset double-counting vulnerability combined with a flash loan to extract excess value in a single transaction.

This case once again highlights a recurring risk in DeFi and Layer 2 vault designs: permissionless asset registration combined with shared underlying collateral can break core accounting invariants.

Incident Overview

RedSonic Vault is an Ethereum-side vault associated with the Reddio ecosystem (a GPU-accelerated Parallel EVM Layer 2). Users deposit ETH to receive rsvETH, which is used for cross-chain operations to Layer 2. A portion of the deposited ETH is allocated to relatively low-risk strategies, with yields distributed proportionally to rsvETH holders.

According to our independent analyses:

• Loss amount: ~9.25 ETH
• Attack type: Flash loan + share price manipulation via asset double-counting
• Root issue: The same stETH was counted toward both the ETH vault and the newly registered stETH vault balances

Technical Root Cause: Cross-Vault Asset Double-Counting

clearly identified the root cause:

stETH deposited into the permissionlessly registered stETH vault is also included in the ETH vault’s getTotalAssetBalance(ETH). As a result, the same stETH simultaneously backs both rsvETH and rsvstETH.

Key contributing factors:

1. The vault supported permissionless registration of new ERC-20 assets (anyone could register stETH and create an rsvstETH share class).
2. Deposited stETH was incorrectly added to the ETH vault’s total asset balance calculation.
3. This artificially inflated the rsvETH share price.
4. The attacker could redeem the inflated rsvETH for excess ETH and then redeem rsvstETH to recover the original stETH — effectively performing a double withdrawal against the same collateral.

A 2% withdrawal cap existed but proved ineffective. Rate limits can only slow the drain; they cannot restore broken accounting invariants once the same underlying asset is allowed to back multiple claims.

Attack Flow (Simplified)

Based on on-chain analysis and reports from researchers (including ExVulSec), the attack unfolded roughly as follows in a single transaction:

1. Flash-loaned approximately 1,139 WETH from Balancer (zero starting capital required).
2. Deposited ~1,130 ETH to acquire the majority of outstanding rsvETH shares.
3. Permissionlessly registered stETH as a new asset class, creating rsvstETH.
4. Deposited ~9.34 stETH, which inflated the rsvETH share price due to double-counting.
5. Redeemed rsvETH for ~1,139.5 ETH (the excess became the profit source).
6. Redeemed rsvstETH to recover the original stETH.
7. Swapped the recovered stETH for ETH on Curve.
8. Repaid the Balancer flash loan and retained ~9.25 ETH profit.

Key Addresses and Transaction

• Attacker: 0x70f2333d21ed7e7d105f6578227a9a747687982c
• Victim Diamond (RedSonic Vault): 0x4315990d9eeaffdfafd49958b4851f203fa1126f
• Vulnerable Vaults Implementation: 0x92ecc5deacb14937867686ca8b85dd8a65b74704
• Main transaction hash: 0xe3cba90e865c6cba950ebce36a52607f51f1fd33cd9fb920c78803f19b57791a

Users and researchers are encouraged to verify the full transaction and event logs on Etherscan.

Security Lessons and Recommendations

This incident exposes several important lessons for vault and share-token designs:

1. Permissionless registration requires strict isolation checks
   When allowing anyone to register new assets, the system must guarantee that the new asset cannot contaminate existing totalAssets or share-price calculations.

2. Shared collateral must never support multiple independent claims
   The same underlying asset should count toward only one vault’s redeemable balance. This is a fundamental invariant.

3. Withdrawal caps cannot fix broken accounting
   Rate limits only restrict speed. They cannot restore solvency once the accounting is already incorrect at deposit time.

4. Flash loans amplify small design flaws
   Zero-capital attacks dramatically lower the barrier to exploitation. Any manipulable share price is high-risk.

Recommendations for projects:

• Audit all permissionless functions thoroughly and consider formal verification.
• Implement asset isolation and strict whitelisting where possible.
• Add continuous cross-vault consistency checks.
• Simulate flash-loan attack scenarios before mainnet deployment.

Recommendations for users:

• Prefer protocols with reputable security audits.
• Exercise extra caution with complex multi-asset vaults or low-TVL designs.
• Monitor for unusual share-price movements or large withdrawals and exit if necessary.

Conclusion

The ~9.25 ETH loss on Reddio’s RedSonic Vault stemmed from a classic cross-vault asset double-counting vulnerability. By combining permissionless asset registration with flawed total-balance accounting, the same stETH was allowed to back both rsvETH and rsvstETH. A flash-loan attacker exploited this to inflate share prices and perform a double redemption.

Although the absolute loss was relatively modest, the pattern is widely applicable to any multi-asset vault, share-token system, or Layer 2 related design. Correct accounting invariants remain non-negotiable.

In DeFi, there are no “small” accounting bugs — especially when flash loans are available.

---

Disclaimer: This article is based on public threat intelligence from PandaSecurity and on-chain analysis. It is intended for security research and educational purposes only and does not constitute investment advice. Always verify information against official sources and on-chain data.

Suggested related keywords for further reading: DeFi vault security, stETH risks, flash loan attack cases, Layer 2 vault audits, asset double-counting vulnerabilities