Alchemy ERC security record

As mentioned in the code comments at L245-L247, session keys are only expected to be used in the user operation context. Therefore, `SessionKeyPlugin` does not define the runtime validation function for `executeWithSessionKey()`, with the assumption that any function call in runtime to `executeWithSessionKey()` will revert due to the lack of validation function. In usual cases, such design should work as expected since `UpgradeableModularAccount` reverts with a `RuntimeValidationFunctionMissing()` error if the validation function corresponding to a runtime call does not exist, except the cases for self-calls to `installPlugin()` or `upgradeToAndCall()`. However, any other installed plugin can add a runtime validation function to `executeWithSessionKey()`, enabling and allowing session keys in runtime. Also, during the runtime call, the session key validation implemented in `userOpValidationFunction()` will be bypassed and not enforced.

In the `_getCombinedSalt()` function of `LightAccountFactory`, the input parameter `owner` is an address, and hence the upper bits are not guaranteed to be 0 when reading its value in assembly. According to the latest [Solidity Inline Assembly documentation](https://docs.soliditylang.org/en/v0.8.25/assembly.html) at the time of writing: > "If you access variables of a type that spans less than 256 bits (for example uint64, address, or bytes16), you cannot make any assumptions about bits not part of the encoding of the type. Especially, do not assume them to be zero. To be safe, always clear the data properly before you use it in a context where this is important […]" Any dirty upper bit in `owner` may lead to a different result of `_getCombinedSalt()` and, therefore, a different account address.

The `LightAccount` wallet supports user operations validation by either EOA or [`ERC-1271`](https://eips.ethereum.org/EIPS/eip-1271) signature validation method. It is important to note that the ERC-1271 signature validation only works when the `owner` of the wallet supports `ERC-1271`. According to the `ERC-1271` standard: > `isValidSignature` can call arbitrary methods to validate a given signature, which could be context dependent (e.g. time based or state based), EOA dependent (e.g. signers authorization level within smart wallet), signature scheme Dependent (e.g. ECDSA, multisig, BLS), etc. Therefore, a contract that supports `ERC-1271` may read storage or the current blockchain state to determine the validity of a signature. However, the usage of `ERC-1271` for the validation of user operations may have specific limitations due to the restrictions of opcode banning and storage access outlined in the [`ERC-4337`](https://eips.ethereum.org/EIPS/eip-4337) standard. Specifically, during the validation phase, wallets are not allowed to use any forbidden opcodes, including `TIMESTAMP` and `NUMBER`. Additionally, storage access is restricted to self-storage or storage associated with the wallet's address. This restriction prevents `ERC-1967` proxies from being an owner of a `LightAccount`, as they access a constant implementation slot not associated with the wallet. These restrictions also mean that violating the storage access rule on the `owner` would lead to bundlers dropping the UserOps that are sent to the `owner`'s light account. While typically, this is recoverable by directly operating on the `owner` smart contract itself, it may not be the expected behavior. There is also the possibility of not being able to recover if the `owner` smart contract is not well designed. Furthermore, the `LightAccount.isValidSignature()` function cannot be used for user operation validation since `LightAccount` is deployed as an `ERC-1967` proxy and implements a customized storage slot pattern that triggers a storage access violation when the wallet attempts to read its `owner`.

In the `LightAccount` wallet, the `owner` can transfer their ownership to another address through the `transferOwnership()` function. This transfer of ownership can occur either directly or by `ERC-4337` user operations. However, the wallet can lose ownership if the `newOwner` address is accidentally provided as an uncontrollable address or a smart contract that does not support `ERC-1271`. As a result, all user operations to the wallet will fail during the validation phase, effectively making the wallet unusable.