Vulnerability Analysis: Deconstructing the $147k Sharwa Finance Exploit

On approximately October 20, 2025, Sharwa Finance, a protocol on Arbitrum, was exploited, resulting in a loss of ~$147,000 from its WETH, and WBTC liquidity pools. While the financial damage is moderate compared to other major DeFi exploits, this incident serves as a powerful and critical reminder of two fundamental principles of Web3 security: the inherent danger of using spot prices as oracles and the necessity of a continuous security lifecycle.

This analysis, based on publicly available transaction data and community reports, breaks down the attack’s mechanics, the root cause, and the procedural failures that allowed it to happen.

• Attacker addresses:

  • 0xaa24987bab540617416b77c986f66ae009c55795

  • 0xd356c82e0c85e1568641d084dbdaf76b8df96c08

• Vulnerable contract: 0xd3fde5af30da1f394d6e0d361b552648d0dff797

• Attack Txs:

  • 0xb0bf77475818b2501e78f0927f4131e52c6efd45bc4978992cbbe218a57e6f7f

  • 0x9f8b4841f805ec50cc6632068f759216d85633fbbe34afde86b97bbc41c23ead

  • 0x35a523bdaf60a9e8b66ab92bb8b78d5012e102e462b665e98ce46f7e07addd36

Anatomy of the Exploit

The attack followed a classic flash loan price-manipulation pattern. The entire operation was executed within a single transaction, traceable on Arbiscan.

1. Flash Loan: The attacker initiated the exploit by taking a massive flash loan of USDC from the Morpho protocol.

2. Price Manipulation: The attacker used this borrowed capital to execute a large swap on a Uniswap V3 pool (e.g., WBTC/USDC). This single, massive trade intentionally unbalanced the pool, causing a severe and artificial distortion of the WBTC price relative to USDC.

   

3. Exploitation: With the pool’s price now manipulated, the attacker interacted with Sharwa Finance’s core logic via its FacadeTradeRouter contract.

4. Flawed Oracle Call: This contract, needing to determine the value of assets, called the getAmountOut function (or a similar function on the Uniswap V3 quoter contract). This function reads the asset price directly from the manipulated pool, returning a highly inaccurate and unfavorable price to the protocol.

   

5. Profit Extraction: Believing this false price, the Sharwa protocol allowed the attacker to perform a privileged action—such as decreaseLongPosition—at an illegitimate exchange rate. This effectively permitted the attacker to withdraw far more assets (in real value) than their position was worth, draining the protocol’s pools.

6. Cleanup: The attacker then swapped the assets back, returning the Uniswap V3 pool to its original state, repaid the Morpho flash loan, and pocketed the difference as profit.

Root Causes

The Technical Flaw (Unsafe Oracles)

The technical vulnerability is a foundational mistake in DeFi protocol design: using a DEX spot price as a price oracle.

The protocol used the Uniswap V3 quoter contract to get the current value of tokens. The problem is that these “values are the result of a simulated swap, given the current state of the pools. This means that these values can be easily manipulated... by using a flash loan.” - protocol’s audit report

The correct, industry-standard solution is to use a robust, decentralized oracle network like Chainlink. Chainlink Price Feeds aggregate data from numerous independent, high-quality sources (both CEXs and DEXs), making them resistant to manipulation from a single flash loan or a single liquidity pool.

The Process Failure (A Forgotten Vulnerability)

More troubling than the technical flaw is the failure in the security process. This was not a novel, zero-day exploit.

According to reports from other security firms, this exact vulnerability was identified and reported by PashovAudits over a year ago during the protocol’s initial audit. At the time, the finding was marked as “resolved.”

However, the vulnerable FacadeTradeRouter contract was a new deployment, created just 18 days before the attack. This strongly suggests that in the process of updating the protocol or deploying new contracts, the developers either:

1. Failed to apply the original fix to the new contract.

2. Did not have the new code audited.

3. Forgot about this finding.

This is a critical breakdown in the security development lifecycle (SDLC). An audit is not a one-time “immunity” stamp; it is a snapshot in time. Any subsequent code change, especially to contracts handling core logic and funds, must undergo the same rigorous security review.

Key Lessons

The Sharwa Finance exploit, while unfortunate, provides clear, actionable lessons for all Web3 builders:

1. NEVER Use Spot Prices as Oracles: This cannot be overstated. Any protocol logic that depends on the price of an asset must retrieve that price from a manipulation-resistant source.

2. Security is a Continuous Process: Security is not a single checkbox you tick at launch. It is a continuous cycle of auditing, monitoring, and validating—especially when code is modified or redeployed.

3. Audit All Changes: A new deployment is a new protocol. Never assume that fixes from an old audit carry over. Every significant change to a live codebase must be reviewed or fully re-audited.

4. Maintain a “Vulnerability Memory”: Past audit findings are invaluable data. Development teams must maintain a strong internal process to ensure that known vulnerabilities are never re-introduced.

At Verichains, we believe in a proactive, continuous approach to security. This incident is a powerful reminder that secure protocol design and a vigilant development process are two sides of the same coin.