A security vulnerability has been identified in the UniswapV3Adapter
contract where a global stored deadline is used for all swap transactions instead of requiring per-transaction deadlines.
The current implementation uses a stored deadline
state variable that is set via setDeadline()
and applies this single deadline across all swap transactions. This architectural decision introduces temporal consistency issues and transaction timing vulnerabilities.
The contract maintains a global deadline state that, once set, governs all subsequent swap operations. This poses security concerns as transaction execution timing becomes predictable and potentially manipulatable. Malicious actors monitoring the mempool can observe the fixed deadline and optimize their transaction ordering to exploit this predictability.
Moreover, the global deadline state fails to account for varying latency requirements across different trading scenarios and market conditions. During high volatility periods, users might require stricter deadline controls, while more relaxed timeframes might be acceptable in stable market conditions. The current implementation prevents this kind of dynamic adaptation.
The vulnerability manifests in the contract's core swap execution logic where the stored deadline is used without transaction-specific validation. In the executeSwapExactInputSingle
function, transactions rely on this global deadline state, creating a uniform time window that could be significantly different from when the transaction was actually submitted.
A particularly concerning scenario arises in MEV contexts, where specialized bots can monitor transactions and manipulate their execution timing. These bots can hold transactions until just before the global deadline expires, potentially executing them under significantly different market conditions than when they were submitted.
The vulnerability can be remediated by implementing transaction-specific deadlines:
The contract should be refactored to remove the global deadline state and associated setter function. All swap-related functions should be updated to include deadline parameters in their signatures. This change ensures that each transaction carries its own timing constraints, allowing for more granular control over execution windows and reducing the attack surface for timing-based manipulations.
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.