Sorpaas

Name of the Vulnerable Software and Affected Versions: ethereum crate versions prior to 0.18.0 Description: The issue concerns a specification deviation in the ethereum crate for Rust, where signature malleability according to EIP-2 was only checked for "legacy" transactions, but not for EIP-2930, EIP-1559, and EIP-7702 transactions. This is not a high-risk security issue, especially if the crate is used on a single-implementation blockchain. Recommendations: For versions prior to 0.18.0, upgrade to version 0.18.0 to resolve the issue. As a temporary workaround, consider manually checking transaction malleability outside of the crate.

**Name of the Vulnerable Software and Affected Versions** rust-evm versions prior to 0.41.1 **Description** The issue is related to the `record external operation` feature in `rust-evm`, which allows library users to record custom gas changes. This feature can have bogus interactions with the call stack, particularly during finalization of a `CREATE` or `CREATE2`. If the substack execution happens successfully, `rust-evm` will first commit the substate and then call `record external operation(Write(out code.len()))`. If `record external operation` later fails, this error is returned to the parent call stack, instead of `Succeeded`. Yet, the substate commitment already happened, causing smart contracts to commit state changes when the parent caller contract receives zero address, which usually indicates that the execution has failed. This issue only impacts library users with custom `record external operation` that returns errors. **Recommendations** For versions prior to 0.41.1, update to release 0.41.1 to resolve the issue. As a temporary workaround, consider disabling the `record external operation` feature until a patch is available. Restrict access to the `record external operation` function to minimize the risk of exploitation. Avoid using the `record external operation` function in the affected API endpoint until the issue is resolved.

**Name of the Vulnerable Software and Affected Versions** Frontier versions prior to commit d3beddc6911a559a3ecc9b3f08e153dbe37a8658 **Description** The issue arises from the worst case weight always being accounted as the block weight for all cases, which can lead to block spamming attacks in case of large EVM gas refunds. An adversary can construct blocks with transactions that have a large amount of refunds or unused gases with reverts, resulting in inflated chain gas prices. The impact of this issue is limited, as the spamming attack would still be costly for any adversary and has no ability to alter any chain state. **Recommendations** For versions prior to commit d3beddc6911a559a3ecc9b3f08e153dbe37a8658, update to a version that includes the fix, as the issue has been patched in commit d3beddc6911a559a3ecc9b3f08e153dbe37a8658. As a temporary workaround, consider properly refunding unused weights after each EVM execution to prevent block spamming attacks.