QuantAMM

Summary

The initialize function in QuantAMMWeightedPool is only protected by the initializer modifier but lacks proper access control. While the initializer modifier ensures the function can only be called once, it does not restrict who can call it. This creates a critical vulnerability where an attacker could front-run the legitimate initialization transaction and initialize the contract with malicious parameters.

The impact of a successful front-running attack would create severe security implications. An attacker who successfully front-runs the initialization could gain control over critical pool parameters, particularly the ability to set malicious initial weights that could be exploited for manipulation. The attacker would also gain control over the oracleStalenessThreshold setting, which could be manipulated to allow stale or inaccurate price data to be accepted by the pool. Furthermore, the ability to register unauthorized or malicious assets in the pool would enable various forms of pool manipulation and potential value extraction.

Since the initializer modifier prevents subsequent initialization calls, the legitimate owner would be permanently locked out of initializing the contract with the intended parameters. This situation would necessitate a complete contract redeployment, resulting in significant operational disruption, gas costs, and potential financial losses for users who may have already started interacting with the compromised contract.

Proof of Concept

https://github.com/Cyfrin/2024-12-quantamm/blob/a775db4273eb36e7b4536c5b60207c9f17541b92/pkg/pool-quantamm/contracts/QuantAMMWeightedPool.sol#L694

Recommended Mitigation Steps

1. Add access control to the initialize function using the onlyOwner modifier:

1. Alternatively, if using OpenZeppelin's Initializable, consider implementing a two-step initialization process where:

• The constructor sets the initial owner

• The initialize function can only be called by that owner