The checkLog
function in UsdTokenSwapKeeper
does not confirm that log.topics[0]
matches the genuine event signature. This omission allows an attacker to create deceptive logs that trigger unwanted or premature Chainlink upkeep processes.
The checkLog
function processes logs to determine if certain actions, such as upkeep or swap requests, need to be performed. It relies on logs emitted by other contracts, which contain topics including the event signature and other relevant data.
However, the function does not verify that log.topics[0] matches the expected event signature. This lack of verification breaks the security guarantee that only intended events trigger contract actions. An attacker can emit logs with arbitrary data, including a valid-looking topics[1] and topics[2], but with an incorrect topics[0]. Without verification, the function processes these logs, leading to unintended behavior.
The impact of this vulnerability is significant because it allows for false triggers and operational disruption. Processing invalid logs can lead to incorrect actions being taken, such as executing swaps with incorrect parameters or failing to execute necessary upkeep. This undermines the reliability and integrity of the contract's operations.
The likelihood of this vulnerability being exploited is moderate. While it requires an attacker to craft specific logs, the absence of event signature verification makes it feasible for an attacker to disrupt contract operations. The reliance on logs for automation increases the risk of this issue being exploited.
Attacker creates a log with log.topics[1]
= legitimate caller address and log.topics[2]
= valid requestId, but log.topics[0]
set to a bogus event signature.
Contract receives the log in checkLog
without signature verification.
Contract calls getSwapRequest
for the user/requestId combination, then attempts to handle or revert based on a fabricated scenario, wasting gas or causing incorrect swap checks.
Implement a verification check on log.topics[0]
to ensure it matches the intended event signature:
This enforces on-chain validation that the log corresponds to the authentic event, eliminating the risk of forged or misleading logs triggering undesired keeper behavior.
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.