Silo is a permissionless, risk-isolating lending protocol providing secure money markets for all token assets. To offer users a convenient way to open leveraged positions, Silo built a new, isolated leverage contract module. Certora performed a manual security review of the new leverage contract between June 9 and June 13. During this period, we identified and flagged several concerns, both potential and concrete, based on the code provided. However, the vulnerability exploited was not identified during that review.

On June 25th, the Silo team informed us that during ongoing testing of the newly introduced leverage module (isolated from the core Silo protocol), an incident occurred in which overly broad approvals inadvertently enabled a borrow manipulation exploit. Importantly, this module is entirely separated from the core Silo contracts - no vaults, markets, or user funds were affected or at risk.

The Silo team asked us to confirm that the other Silo contracts, which we have extensively audited in addition to other teams and formally verified, are unaffected by this vulnerable contract.

Detailed step-by-step explanation is documented in the following sections by Silo.

Incident Timeline (UTC) – June 25, 2025

• 14:11 –  First attack on mainnet.
• 14:20 – Second attack on mainnet.
• 14:29 – Hypernative flagged both attacker addresses and alerted centralized services and exchanges.
• 14:34 – The leverage contract was paused.
• 14:44 – Two attacks on Sonic.
• 14:47 – Silo team announced to us via Twitter, Telegram and Discord that the leverage contract was paused.
• 15:01 – Silo team informed Certora that the leverage contract was exploited and some funds were lost.
• 15:16 – Zeroshadow and Hypernative requested that Etherscan label the attacker addresses as Silo Finance Exploiters.
• 15:30 – Certora was added to the Silo incident Telegram group. At this point:
• - The leverage contract was already paused.
• - Hypernative had identified the vulnerability.
• 15:45 – Certora confirmed the root cause internally and came up with recommendations for remediation.
• 17:00 – Certora and Silo held a meeting to confirm the details of the exploit, discuss mitigation steps, and align on the recommended fix. During the meeting, Certora also confirmed that the vulnerability was strictly limited to users who had already opened leverage positions through the isolated leverage contract. All other components of the Silo protocol were unaffected by the issue.

Post-Incident Risk Assessment

Following the immediate triage and identification of the vulnerability, we conducted a focused risk assessment to determine whether additional user funds or components of the Silo protocol were at risk.

• We examined whether the exploit could extend beyond the leverage contract and impact core components of the Silo protocol, including vaults and markets.
• We verified that the vulnerability stemmed solely from the isolated leverage contract and that it did not compromise or interact with the core protocol logic.
• We also evaluated whether pausing the leverage contract was sufficient to contain the issue, and confirmed that this action fully mitigated the vulnerability.
• Ultimately, we concluded that there were no further risks beyond the specific leverage positions already opened. Given that the contract was in the testing phase, no Silo users have open positions in the leverage contract, therefore none are at risk.

This analysis gave Certora and the Silo team confidence that the exploit was fully contained and did not affect user-facing components or funds.

What Went Wrong?

The biggest mistake Certora made was not employing our Formal Verification tool, the Certora Prover, despite having done so for all other Silo contracts, including simpler ones than Leverage.

Additionally, our manual security review did not provide specific recommendations to the Silo team regarding the risks of a user-controlled exchange proxy, only general recommendations on whether an address is a valid silo.

Typically, our security researchers collaborate with our formal verification experts to identify and prevent issues. In this case, even running the Certora Prover without a specification would uncover the problematic code as potentially user-controlled. No rule can be verified without determining what the impact of a call to an arbitrary contract would be. If both security researchers and formal verification researchers had discussed this particular external call internally, the bug would have been found.

Lessons Learned

We are in continuous communications with the Silo team regarding remediation and a fix plan. We are conducting an additional security review of the code and formally verifying it to achieve the highest level of security assurance, ensuring it meets the same level of confidence we have in all other Silo contracts. All deployed Silo contracts except for Leverage underwent both a security review and formal verification.

We made a mistake: the isolated Leverage contract contained an overly broad approval that allowed an attacker to manipulate borrowing. This was exploitable because of a lack of validation of external inputs, which created a window for the exploit.

Fortunately, the issue was fully isolated and only impacted the new Leverage module. All existing Silo core components, including markets, vaults, and user funds, remain fully secure and unaffected. By pausing the Leverage contract immediately, the exploit was effectively mitigated.

We have learned important lessons about limiting approvals, whitelisting external calls, and strengthening validation. We have also learned that the most effective security review includes both manual review and formal verification, as both approaches are complementary in identifying subtle attack vectors.

Bottom Line

Silo user funds were never at risk since the new contract was in a testing phase and the funds came from Silo’s own accounts, not of users. 

All currently live Silo code is secure.