DeFiLayer 1Layer 2
14,723 OP
View results
Submission Details
Severity: high
Invalid

State Root Verification Risks in ScrvusdVerifierV2.sol

Summary

The ScrvusdVerifierV2 contract relies entirely on an external oracle (IBlockHashOracle) to verify state roots when extracting data from proofs. If this oracle is compromised or manipulated, an attacker could submit falsified proofs, leading to incorrect updates of critical protocol parameters.

Vulnerability Details

Affected Functions:

  • verifyPeriodByBlockHash

  • verifyPeriodByStateRoot

Issue Description:

Both functions use IBlockHashOracle.get_state_root(_block_number) and IBlockHashOracle.get_block_hash(block_header.number) to verify proof authenticity. However, no additional verification exists to validate whether the returned state root is correct. If the oracle is compromised, an attacker can provide an incorrect state root, making the contract process invalid data.

Code References:

bytes32 state_root = IBlockHashOracle(ScrvusdVerifierV1.BLOCK_HASH_ORACLE).get_state_root(_block_number);
require(
block_header.hash == IBlockHashOracle(ScrvusdVerifierV1.BLOCK_HASH_ORACLE).get_block_hash(block_header.number),
"Blockhash mismatch"
);

Impact

  • Funds at risk: If manipulated state roots allow forged proof submissions, financial parameters like profit_max_unlock_time can be arbitrarily modified.

  • Protocol Disruption: Incorrect parameter updates could disrupt user balances, liquidity functions, and overall financial integrity of the protocol.

  • Loss of Trust: If an attacker exploits this issue, users may lose confidence in the security of the protocol.

Tools Used

  • Manual code review

  • Static analysis of state root verification logic

Recommendations

  1. Add Secondary Validation: Implement an additional verification mechanism to ensure state root correctness before accepting proofs.

  2. Decentralize Oracle Inputs: Use multiple oracles for consensus-based state root verification rather than relying on a single oracle.

  3. Implement Emergency Fallbacks: Add an emergency function that can disable state root-based updates if an anomaly is detected.

Updates

Lead Judging Commences

0xnevi Lead Judge 5 months ago
Submission Judgement Published
Invalidated
Reason: Out of scope
Assigned finding tags:

[invalid] finding-block-number-no-input-check

- Anything related to the output by the `BLOCK_HASH_ORACLE` is OOS per \[docs here]\(<https://github.com/CodeHawks-Contests/2025-03-curve?tab=readme-ov-file#blockhash-oracle>). - The PoC utilizes a mock `BLOCK_HASH_ORACLE`which is not representative of the one used by the protocol - Even when block hash returned is incorrect, the assumption is already explicitly made known in the docs, and the contract allows a subsequent update within the same block to update and correct prices - All state roots and proofs must be verified by the OOS `StateProofVerifier` inherited as `Verifier`, so there is no proof that manipulating block timestamp/block number/inputs can affect a price update - There seems to be a lot of confusion on the block hash check. The block hash check is a unique identifier of a block and has nothing to do with the state root. All value verifications is performed by the OOS Verifier contract as mentioned above

Support

FAQs

Can't find an answer? Chat with us on Discord, Twitter or Linkedin.