QuantAMM

01. Relevant GitHub Links

• https://github.com/Cyfrin/2024-12-quantamm/blob/a775db4273eb36e7b4536c5b60207c9f17541b92/pkg/pool-hooks/contracts/hooks-quantamm/UpliftOnlyExample.sol#L353C1-L371C1

02. Summary

The onRegister function in the UpliftOnlyExample contract does not validate whether the pool being registered originates from a trusted (or “allowed”) factory. This omission enables any arbitrary pool—potentially malicious—to be registered, contradicting Balancer’s recommended security pattern that checks for factory authenticity when hooking into existing pool types.

03. Vulnerability Details

According to the Balancer v3 documentation, onRegister should verify two conditions:

1. That the factory address is the one expected (factory == _allowedFactory).

2. That the factory actually created the pool (IBasePoolFactory(factory).isPoolFromFactory(pool)).

For example, Balancer’s sample implementation is:

However, in UpliftOnlyExample.sol, there is no such check:

Without verifying the pool and factory, attackers could register untrusted pools that might contain malicious logic or fail other security checks, thus exposing users and assets to unexpected behaviors or loss.

04. Impact

• Exposure to Malicious Pools: Users might unknowingly interact with pools that have been registered through an untrusted factory.

• Bypass of Balancer Security Practices: The standard Balancer approach is bypassed, undermining the intended safety of hooking into only vetted pool implementations.

• Potential for Unrestricted Feature Use: Since the hooks expect to rely on the pool’s donation/unbalanced liquidity checks, skipping factory validation opens up the possibility for unintended or malicious features to be utilized without detection.

05. Tools Used

Manual Code Review and Foundry

06. Recommended Mitigation

• Implement Factory Verification:

Add checks to onRegister similar to the Balancer v3 example. For example: