Alchemy ERC security record

Plugins can register hooks to offer custom functionality during various stages of a user operation or runtime transaction. However, a malicious plugin can abuse this by introducing hooks that consistently revert, preventing the user from uninstalling the plugin or upgrading the account. As arbitrary selectors can be specified, this could completely brick the account. This issue outlines the most significant impact of the dangers of the plugin trust model. Other cases are covered in MSCA-10.

Plugins can define pre- or post-execution hooks to a specific execution function, which allows them to perform additional validations or modify states before or after the execution function call. However, when a plugin receives a call to its pre-execution hook, it should not assume that the state at the time of the pre-hook call will remain unchanged when the execution function is called. This is because the MSCA implementation allows overlapping hooks, so multiple pre-hooks can be executed after the current pre-hook but before the execution function call. Furthermore, The execution order of the hooks cannot be enforced by the plugins and depends on the account's internal state. Therefore, validation in a pre-hook based on the current state may no longer be valid if the state being checked is changed by another pre-hook before the execution function call. For example, the `SessionKeyPermissionsPlugin` defines a pre-execution hook, which invokes the `_updateLimitsPreExec()` function to update the ERC-20 token spend limits of a session key based on the `transfer()` or `approve()` value. If the call is `approve()`, this function relies on the current allowance to the spender to calculate the increase in the amount spent. However, such a calculation can be erroneous as it assumes no allowance change will occur after the current pre-hook call. A similar issue may exist in post-hooks and validation hooks as well. For example, the state at the time of a post-hook call may not be the exact state after the execution function is executed since there may be other post-hooks in between and change the state.

For `mode 1, 2 and 3` the `paymasterData` field is structured in the following way: ``` For v0.6 // ERC-20 format: // - [0:20] 20 bytes for paymaster // - [20:52] 32 bytes for sigTimeRange // - [52] 1 byte for mode (0: pre-approval, 1: post-op, 2: permit) // - [53:85] 32 bytes for conversion factor (scaled token price, calculated off-chain) // PRICE_SCALE * ethPriceUsd * 10^tokenDecimals / (tokenPriceUsd * 10^(ethDecimals)) // - [85:105] 20 bytes for token address // - [105:125] 20 bytes for receiver address // - [125:190] 65 bytes for signature // - [190:] variable bytes for permit (if mode == 2) For v0.7 // ERC-20 format for paymaster data: // - [0] 1 byte for mode (0: pre-approval, 1: post-op, 2: permit) // - [1:33] 32 bytes for conversion factor (scaled token price, calculated off-chain) // PRICE_SCALE * ethPriceUsd * 10^tokenDecimals / (tokenPriceUsd * 10^(ethDecimals)) // - [33:53] 20 bytes for token address // - [53:73] 20 bytes for receiver address // - [73:138] 65 bytes for signature // - [138:] variable bytes for permit (if mode == 2) ``` For example, in the context of paymaster v0.7, the bits 138 onwards are only used in `mode = 2`, but there is no enforcement that the field is not used during `modes = 0` and `1`, which could lead to wasted gas due to byte stuffing. The only check currently enforces the `paymasterData ` to be at least 138 bits. There are no direct exploits here, as this byte stuffing would cause a loss for the user because both the paymaster and the user have to sign this data. There is only one case where the paymaster loses some funds, and that is in `mode 1`, where the user does not pay in `postOp`. However, it would be a good practice to avoid this griefing vector.

The paymaster implementation for EntryPointv0.6 contains a `POST_OP_GAS ` constant that is a snapshot measure of the gas-costs of the `postOp()` call with USDC as the ERC-20-payment token. This is used as this version of the EntryPoint lacks a granular parameter for limiting the `postOp` gas that is needed for the cost calculations. The single value is slightly simplifying the mechanics of the different modes of operation. In `mode = 0`, there is for example not just one, but two `safeTransfers()` compared to `mode = 1`. Some tokens might have differing gas costs for their transfers, especially if e.g. ERC-777 or ERC-1155 tokens with callbacks are used. Different chains might also have different gas costs for certain opcodes that are used in this call. Furthermore, in the version supporting EntryPointv0.6, there is also the possibility of reverts, leading to a second invocation of the `postOp()` call that incurs additional gas costs not captured by this constant. We also want to mention that there are very select few chains that adjust the gas costs of certain opcodes most notably [ZKSync](https://docs.zksync.io/zksync-protocol/rollup/fee-model#different-opcode-pricing), that could lead to inaccuracies with the same value between different chain deployments.

The `VerifyingPaymaster` contract applies a 10% gas penalty in the `postOp()` function based on the **total gas limit**, rather than strictly the **unused execution gas**, contrary to the ERC-4337 specification. The penalty is currently calculated as: ```solidity uint256 gasPenalty = (totalGasLimit * actualUserOpFeePerGas - actualGasCostWithPostOp) / 10; ``` This calculation incorrectly penalizes users for unused pre-operation gas, inflating their final charge. According to the [ERC-4337 specification – Required EntryPoint Contract Functionality](https://eips.ethereum.org/EIPS/eip-4337#required-entrypoint-contract-functionality), the `UNUSED_GAS_PENALTY_PERCENT` (10%) should be applied only to unused gas from `callGasLimit` and `paymasterPostOpGasLimit`.

In the flow of using this paymaster, the `UserOperation` sender proposes a `UserOperation` to the paymaster signer API, which calculates the appropriate user token payment and encodes these values into the `paymasterAndData` field of the `UserOperation` struct. The user then confirms this data again by providing a passing validation for the full `UserOperation`. Apart from these off-chain calculations by the Paymaster, the actual gas costs of the `UserOperation` and the token amount are not associated with each other, so the users essentially opt in to some token payment, no matter the actual execution costs. The gas costs could be significantly differ from the underlying ERC-20-payment if the `conversionFactor`, the value indicating the conversion between ETH and the token the user is paying in, is wrongly calculated. In volatile token price conditions, it could also be the case that the signer API signs off a significantly lower `conversionFactor`, resulting in a monetary loss of the paymaster. A compromised signer API could also withdraw the full approval from the `UserOp.sender` in a requested `UserOperation`. If the end user does not detect that when providing the validation for the `UserOperation`, they might be left at a significant financial loss.

The standard specification of ERC-7597 uses a `block.timestamp` check to check for freshness of the forwarded `deadline` parameter. However, as defined by ERC-7562, this is a forbidden opcode for the validation phase of `UserOperations` according to OP-011, which would result in default bundlers dropping such `UserOperations`, ultimately not including them in bundles on-chain. Some token implementations support ERC-7597, but skip the `block.timestamp` check if a `uint256.max` value is encoded as part of the deadline of the permit. An example of such a token is USDC. Such implementations would not lead to ERC-7562 complications.

The `_validatePaymasterUserOp()` function includes state-dependent reverts that might change in outcome between after second validation and final simulation/execution on the chain, such as paymaster being paused, signer being updated, or allowances/permits being consumed. If validation produces different results for the same `UserOperation` after the second validation simulation, bundlers may ban the paymaster, stopping UserOperations including this paymaster from being propagated. This aligns with [GREP-40](https://eips.ethereum.org/EIPS/eip-7562#general-reputation-rules) from ERC-7562, which emphasizes deterministic validation to prevent bans. Here is a non-exhaustive list of where this might occur: 1. Both Paymasters could be paused via `pause()`. Depending on when the function is called, there can be a case where `UserOperation` is invalidated just before on-chain execution. 2. Signer can be updated via `updateVerifyingSigner()`, which could lead to signature validation failing and there can be a case where `UserOperation` is invalidated just before on-chain execution. 3. Permit or approval can be withdrawn just before the `UserOperation` is executed on-chain.

With ERC-6900 v0.8, self-calls to the account are strictly reserved to indicate authorization to invoke some selector. Therefore, the ways in which the account can call itself are very important. The `executeBatch()` function is such a case. In case it performs a self-call, that call's selector is analyzed and has to also be able to be validated by the current validation. However, the actual validation, including the validation associated execution hooks, is then not performed, if invoked via a self-call, only the hooks for the outer `executeBatch()` call is performed. This is known and documented, but we wanted to emphasize it in the report, as well. If some entity has access to `executeBatch()`, but also to some by hooks heavily protected execution function, the hooks of that other selector can be bypassed by performing an `executeBatch()` self-call encoding that other execution function.

Within the `ExecutionLib` library, various low-level calls such as `delegatecall()`, `staticcall()`, and `call()` are made without sufficient safeguards, specifically a lack of: 1. `returnsize()` checks 2. `extcodesize()` checks <br> This oversight is concerning, particularly in the context of EIP-7702, where an Externally Owned Account (EOA) could temporarily function as a module when invoking `installExecution()` or `installValidation()`. This scenario could allow subsequent hook calls to succeed improperly without verification. A similar risk exists with standard module installations where no `installData` is used for callbacks or interface checks. Additionally, if a module self-destructs after installation, these unchecked calls may continue to pass, leading to potential security vulnerabilities.