HACK ANALYSIS 5 min read

Dexodus Finance Hack Analysis


Dexodus Finance Hack Analysis

Overview:

On May 26, 2025, Dexodus Finance (@DexodusFinance) suffered a price manipulation exploit in its leverage module, resulting in a loss of approximately $291,000. The exploit was due to improper freshness validation of Chainlink oracle reports passed via performUpkeep() calls.
 The attacker supplied a valid but stale Chainlink report to enter a leveraged long at an artificially low price, then immediately closed the position at the correct higher price within the same transaction. This vulnerability falls under OWASP SC02:2025 Price Oracle Manipulation.

Smart Contract Hack Overview:

Fig: Attack Transaction

Decoding the Smart Contract Vulnerability:

  • The root cause of the exploit in the perpetuals market liquidity pool, lies in the absence of a data freshness check in the performUpkeep() function, coupled with inadequate replay protection in the Chainlink price report verification process. The attacker called this function twice in a single transaction — first to open a position at an outdated price of ~$1816 (log: indexPrice = 1,816,830,254) and then to close it at the current market price of ~$2,520 (log: indexPrice = 2,520,617,081), profiting ~$300,000
  • Chainlink price reports are cryptographically signed and remain valid for a specific period (up to a month, as noted in the Chainlink Data Streams guide). However, for high-frequency trading applications like perpetual futures markets, price data must reflect real-time market conditions (often within seconds).
Fig: Vulnerable performUpkeep() Function
  • The performUpkeep() function is responsible for processing price reports and modifying positions in the perpetuals market. It decodes a Chainlink price report, verifies it, and uses the price to modify a position.
  • The performUpkeep() function did not verify the timestamp or recency of the submitted Chainlink price report, allowing the attacker to use an older report (approximately one month old) with a significantly lower price (~$1,800) compared to the current market price (~$2,500).
  • This oversight violated a critical warning in the Chainlink Data Streams guide, which emphasizes the need for application-level checks to ensure data freshness.
  • The _currentPrice derived from the outdated report was used to open the position, while the closing price used a fresher price feed, enabling the price manipulation. The attacker constructed a performData input for performUpkeep(), including an outdated Chainlink price report with a price of ~$1,816
  • The report was cryptographically valid and within Chainlink’s validity window (up to a month), so it passed the verify.verify() function’s checks.
Fig: Vulnerable verify() Function
  • In the verify()function, the signedReport is decoded, extracting reportContext (which includes the epoch and round) and reportData (which includes the price and timestamp).
  • The reportContext[0] is used as the configDigest, and reportContext[1] contains the epoch and round. The function does not validate reportContext[1]to ensure the report is recent ( by comparing the epoch/round to a recent value).
  • This incident drained the pool to ~$1,000, highlighting the need for DeFi protocols to rigorously audit oracle integrations and implement application-level checks as per Chainlink’s guidelines.
  • Dexodus finance team worked with various security teams to investigate the incident and promptly recover the funds. all the affected users will be refunded soon, said the tweet. Here is the update on it: https://x.com/DexodusFinance/status/1927392460684067031
Fig: Funds Recovered Tweet

Mitigation and Best Practices:

  • To prevent this types of vulnerabilities, add a timestamp validation to ensure the Chainlink price report is recent, such as requiring the report’s timestamp to be within 10 seconds of the current block timestamp. So, ensure that oracle data (e.g., Chainlink price feeds) is validated at the application level for freshness and relevance, especially in high-frequency trading scenarios like perpetual futures markets.
  • Introduce a mechanism to prevent replay attacks by tracking used epochs or nonces in the verify function. Incorporate anti-replay mechanisms in smart contracts that rely on external data feeds, such as tracking nonces, epochs, or report hashes to prevent the reuse of previously submitted data.
  • Also, use the same price feed or enforce the same freshness criteria for both opening and closing positions.Mitigate price manipulation risks by using time-weighted average prices (TWAP) or aggregating data from multiple oracles to ensure price accuracy, rather than relying on a single data point.
  • To prevent such vulnerabilities, the best Smart Contract auditors must examine the Smart Contracts for logical issues. We at CredShields provide smart contract security and end-to-end security of web applications and externally exposed networks. Our public audit reports can be found on https://github.com/Credshields/audit-reports. Schedule a call at https://credshields.com/
  • Scan your Solidity contracts against the latest common security vulnerabilities with 494+ detections at SolidityScan.
Fig: SolidityScan — Smart Contract Vulnerability Scanner

Conclusion:

SolidityScan is an advanced smart contract scanning tool that discovers vulnerabilities and reduces risks in code. Request a security audit with us, and we will help you secure your smart contracts. Signup for a free trial at https://solidityscan.com/signup

Follow us on our Social Media for Web3 security-related updates.

SolidityScan — LinkedIn | Twitter | Telegram | Discord