In the ScrvusdVerifierV1
contract related to the lack of validation for return values from Oracle update functions. The contract fails to perform any validation on the price values returned by the oracle, which could lead to the propagation of incorrect, manipulated, or extreme values throughout the system. This vulnerability creates a potentially serious risk to the integrity and security of the price feed mechanism that could impact the entire ecosystem relying on this data.
The vulnerability is present in both the verifyScrvusdByBlockHash
and verifyScrvusdByStateRoot
functions, which ultimately call the SCRVUSD Oracle's update_price
function through the _updatePrice
function:
The main issues are:
Both functions directly return the value from _updatePrice
without any validation.
There are no checks to ensure the returned price is within reasonable bounds.
There is no verification that the oracle update was successful, rather than returning a default or error value.
The code lacks any circuit breakers or sanity checks for extreme price changes.
From the available code, it appears that the _updatePrice
function likely calls the oracle's update_price
method defined in the IScrvusdOracle
interface:
Without proper validation, any value returned by this function is blindly accepted and propagated through the system.
The impact of this vulnerability is:
Price Manipulation: Incorrect or manipulated price data could be accepted and propagated throughout the system, potentially leading to financial losses.
Flash Loan Attacks: Without validation, attackers might exploit flash loans to manipulate underlying parameters that affect the price calculation.
Cascading Failures: Other protocols relying on this price feed could make incorrect financial decisions based on invalid data.
Economic Exploits: Extreme price values could be used to drain liquidity pools or manipulate collateralization ratios in lending protocols.
System Instability: Unexpected price movements could trigger liquidations or other automated actions that destabilize the ecosystem.
The likelihood of this vulnerability causing issues is assessed as MEDIUM based on:
Systemic Pattern: The lack of validation is consistent across multiple functions, indicating a systemic design issue.
Critical Functionality: Price updates are fundamental to DeFi operations, making this a high-value target for attackers.
Compound Risk: This vulnerability exacerbates other identified issues in the codebase, such as timestamp surrogate problems and unverified slot existence.
Market Conditions: Even without malicious intent, extreme market volatility could lead to price values that should be validated or smoothed.
Precedent: Similar vulnerabilities have been exploited in other DeFi protocols, resulting in significant financial losses.
The chances of exploitation are significant in a production environment, especially considering the financial incentives for attackers and the critical nature of price data in DeFi ecosystems.
Manual code review
Static analysis
Contextual analysis of the oracle system architecture
Pattern recognition across the codebase
Implement Bounds Checking: Add reasonable upper and lower bounds for price values:
Add Rate-of-Change Limits: Implement checks for maximum allowed price changes between updates:
Implement Circuit Breakers: Add mechanisms to pause price updates during extreme conditions:
Return Status Codes: Modify the oracle interface to return status codes alongside prices:
Implement Time-Weighted Average Prices (TWAP): Use time-weighted averages to smooth price updates and reduce the impact of short-term manipulations.
Add Comprehensive Logging: Implement detailed event logging for price updates, including all input parameters and validation results.
By implementing these recommendations, particularly the first two, the contract can significantly reduce the risk of accepting and propagating invalid price data, thereby enhancing the security and reliability of the entire system.
- See [here]([https://github.com/CodeHawks-Contests/2025-03-curve?tab=readme-ov-file#blockhash-oracle)](https://github.com/CodeHawks-Contests/2025-03-curve?tab=readme-ov-file#blockhash-oracle) on how it is used to verify storage variable - All state roots and proofs must be verified by the OOS `StateProofVerifier` inherited as `Verifier` (where the price values and params are extracted), so there is no proof that manipulating timestamp/inputs can affect a price update - It is assumed that the OOS prover will provide accurate data and the OOS verifier will verify the prices/max unlock time to be within an appropriate bound/values - There is a account existance check in L96 of `ScrvusdVerifierV1.sol`, in which the params for price updates are extracted from
The contest is live. Earn rewards by submitting a finding.
This is your time to appeal against judgements on your submissions.
Appeals are being carefully reviewed by our judges.