Summary

The module type argument is not checked or included in the signature, allowing its malleability and allowing potential installations of a different type of module than intended.

Vulnerability Details

The Nexus smart account supports a "Module Enable Mode" flow in which a user operation may include additional information to install a module before validating a user operation in validateUserOp().

When isModuleEnableMode() is true, the implementation calls _enableMode() with the address of the validator and the signature of the user operation.

As we can see, the signature is first parsed using parseEnableModeData() which extracts the type of the module (moduleType), its init data (moduleInitData), and the inner signature corresponding to this action (enableModeSignature). It then checks if the signature is valid using _checkEnableModeSignature() and proceeds to install and setup the module using _installModule().

However, the digest used to validate the signature doesn't include the module type in its payload:

This means that the moduleType argument is not validated using the bundled signature, allowing its malleability.

Impact

The type of a module used during the "Module Enable Mode" flow can be maliciously manipulated by third parties, allowing the installation of a different type of module than intended.

Furthermore, the logic assumes the installed module is of the validator type, since it doesn't check that a validator with the given address is installed, as opposed to the path where isModuleEnableMode() is false (line 105).

Tools Used

None.

Recommendations

Either add the module type to the signature, or verify that the module type belongs to the validator category.