Summary

A security vulnerability has been identified in the ScrvusdVerifier contracts used in the Curve Storage Proofs protocol. The verifier contracts extract storage values from Ethereum state proofs but fail to verify that the proofs are from the correct contract implementation by checking the code hash. This could allow an attacker to submit proofs from a different or compromised contract with the same address, potentially manipulating cross-chain scrvUSD price oracles.

The _extractParametersFromProof and _extractPeriodFromProof functions in the ScrvusdVerifierV1 and ScrvusdVerifierV2 contracts respectively verify that an account exists at the expected scrvUSD address, but do not verify that the account contains the expected contract code:

The Account struct returned by extractAccountFromProof contains a codeHash field, but the contracts never check this value against an expected hash.

Impact

The absence of code hash verification creates a critical verification gap in the cross-chain state attestation mechanism. When the verifier extracts storage values using Merkle Patricia proofs, it correctly checks that an account exists at the scrvUSD address but fails to validate the contract's implementation bytecode. This incomplete verification allows the extraction of potentially arbitrary values from any contract deployed at that address across different blockchain states or networks.

In contract upgrade scenarios, particularly those using proxy patterns common in DeFi, the storage layout could change while maintaining the same contract address. Without code hash validation, the verifier would blindly extract data from predetermined slots regardless of whether they still correspond to the intended parameters. This creates a dangerous semantic gap between what the verifier believes it's extracting (e.g., profit unlock time) and what those storage slots actually contain post-upgrade.

This vulnerability directly compromises the integrity of cross-chain scrvUSD price data. Since the oracle relies on these parameters to calculate yield accrual rates, manipulated values could accelerate or decelerate price movements, creating arbitrage opportunities exploitable across the protocol's multi-chain deployment. Liquidity pools using oracle-derived scrvUSD prices would be particularly vulnerable, as attackers could extract value through trades executed against incorrectly priced assets while the underlying economic model remains compromised.

Remediation

Implement code hash verification in both _extractParametersFromProof and _extractPeriodFromProof functions:

The EXPECTED_CODE_HASH value should be the keccak256 hash of the deployed scrvUSD contract's runtime bytecode. This should be updated whenever the contract implementation legitimately changes through proper governance procedures.