How Silo Finance Lost $500k+ due to Improper Input Validation
Discover how Silo Finance lost over $500K due to improper input validation. Learn the attack flow, impact, and how it could have been prevented.
Silo Finance is a lending and borrowing protocol which provide isolated pools feature to gain exposure to only certain assets of user’s choice.
The attack occurred on a pre-release leverage smart contract on the Ethereum Mainnet and Sonic which is separate from Silo core contracts. It happened on June 25, 2025, at 2:11:23 PM UTC, leading to the loss of 224 ETH (valued at ~550k at the time of writing). The analysis covers the hack details, how it happened, the attack flow, and the funds lost.
Hack Analysis and Its Impact
LeverageUsingSiloFlashloanWithGeneralSwap is the pre-release contract that got targeted and is deployed at the address 0xCbEe4. The attacker essentially placed malicious swapArgs, which set the attacker's address as the receiver and the victim's address as the borrower. The victim's address has given maximum allowance of the assets to the contract, which led to this attack.
The following function takes in the _swapArgs as an argument, but doesn’t validate the data. As per the report from the protocol, the input was meant to execute swap, but the malicious data led to executing borrow, keeping the victim address as the owner.
The above vulnerability completed the borrowing on the victim’s behalf. Since the leverage contract had borrowing rights from the victim, the attacker set the victim's address as the borrower and their address as the receiver of the tokens.
The funds belonged to siloDAO, and no user funds were harmed during the process.
Understanding the Root Cause
The core vulnerability is in the following line of code, which doesn’t validate the calldata provided in swapArgs and execute the borrow using the victim’s collateral.
Prevent Costly Exploits Like Silo Finance
Prevent Costly Exploits Like Silo Finance
Don’t let a simple validation miss cost you millions. Let QuillAudits review your smart contracts to spot and eliminate such critical loopholes before they go live.
Relevant Transactions, Addresses, and Fund Flow
Attack Contract: 0x79C5c002410A67Ac7a0cdE2C2217c3f560859c7e
Attacker Address #1: 0x04377cfaF4b4A44bb84042218cdDa4cEBCf8fd62
Attacker Address #2: 0x03aF609EC30Af68E4881126f692C0AEC150e84e3
Victim Contract: 0xCbEe4617ABF667830fe3ee7DC8d6f46380829DF9
Victim Address: 0x60baf994f44dd10c19c0c47cbfe6048a4ffe4860
Tornado Cash Fund Transaction to Address #1: 0xb8567f70d61c070ac298ae9924bacdaac8bdbec8c7d71fa0e5d2fab030ddf035
Team’s Attempt to gain the funds back: 0x539ae567fc6ade3cf089c593855855a7522176b8ab48b8613a6a71ce1b67950b
More recently, the address 0x3aF60 routed the funds (224 ETH) through Tornado Cash in multiple transactions:
How the Hack Could Have Been Prevented?
The issue was with the validation of the calldata provided by the users; the contract doesn’t verify the data submitted and execute it, which led to the loss of the victim’s collateral. Validation of user-provided data is essential, and that’s what the protocol should’ve done in the first place.
Conclusion
Silo Finance pre-released smart contract got exploited that led to the loss of over $550k of the victim’s assets. The attacker used the malicious arguments which was not verified by the function, and the intended transaction of swap was converted to a borrow transaction. It is very important to validate the user provided data.
At QuillAudits, with our 7+ years of experience and 1M+ lines audited, we make sure your code is safe and prevent it from different vulnerabilities.
Contents
