Part 2

Summary

In the fulfillSwap function, the keeper-provided parameter address engine is used to set the stablecoin token (usdToken) from the configuration without verifying that the passed engine matches the engine associated with the vault. This can lead to using an incorrect USD token and cause unexpected state changes.

Vulnerability Details

In the current implementation the function:

• Accepts priceData from an external keeper without verifying that it is intended for the current blockchain.

• Does not verify any contextual identifiers (like chain id, nonce, or unique request id) that bind the data to a specific deployment.

• This creates a risk that a keeper could replay the same off‑chain price data on different chains (in a multi‑chain environment) allowing unauthorized or double fulfillment of swap requests.

• For example, the pseudo‑code below shows the basic logic of the problematic function:

Impact

An attacker or misconfigured keeper operating in a cross‑chain scenario could replay the same price data on a different chain. This could lead to multiple approvals of the same swap request, causing incorrect asset transfers, double fulfillment, or other systemic inconsistencies.aq

Tools Used

• Manual code review

• Static analysis (e.g., Slither, MythX)

• Fuzz testing

Recommendations

• Parameter Verification: Rigorously validate the engine parameter against known registered engines in the system.

• Tight Access Controls: Use internal mappings or require additional context (e.g., linking vault IDs with the expected engine) to enforce correctness.

• Nonce or Timestamp Checks: Require a nonce or time‑bound parameter in the price data to ensure one‑time usage.

• Testing: Implement unit tests that simulate incorrect engine inputs.