The vulnerability exists in the oracle data fetching logic where the code doesn't properly validate the oracleResult.data when switching between backup oracles. When a primary oracle is stale, the code moves to backup oracles but fails to validate if the last successful oracle data is actually valid (non-zero).
Consider this scenario:
Primary oracle becomes stale
First backup oracle returns {timestamp: now, data: 0}
The code accepts this as valid data because only the timestamp is checked
Zero or invalid price data gets propagated to weight calculations
If a backup oracle returns a timestamp that's fresh but with invalid/zero data, the function will accept this data without validation
This could lead to incorrect weight calculations in the pool since the oracle data is used to determine asset weights
An attacker could potentially manipulate pool weights if they can cause oracles to return valid timestamps with manipulated data
Manual review
Add data validity check:
Multihop will call ChainlinkOracle and the check is in it: `require(data > 0, "INVLDDATA");` MultiHop is just here to combine Chainlinks feed when there is no direct USD price feed for a token.
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.