evm CVEs · Critical

CVE	Severity	Published▾	Status	Exploitation	Description
CVE-2025-55705	Critical	2026-01-22	Not applicable	No public exploit	This vulnerability occurs when the system permits multiple simultaneous connections to the backend using the same charging station ID. This can result in unauthorized access, data inconsistency, or potential manipulation of charging sessions. The lack of proper session management and expiration control allows attackers to exploit this weakness by reusing valid charging station IDs to establish multiple sessions concurrently.
CVE-2025-54816	Critical	2026-01-22	Not applicable	No public exploit	This vulnerability occurs when a WebSocket endpoint does not enforce proper authentication mechanisms, allowing unauthorized users to establish connections. As a result, attackers can exploit this weakness to gain unauthorized access to sensitive data or perform unauthorized actions. Given that no authentication is required, this can lead to privilege escalation and potentially compromise the security of the entire system.
CVE-2024-32644	Critical	2024-04-19	Not applicable	No public exploit	Evmos is a scalable, high-throughput Proof-of-Stake EVM blockchain that is fully compatible and interoperable with Ethereum. Prior to 17.0.0, there is a way to mint arbitrary tokens due to the possibility to have two different states not in sync during the execution of a transaction. The exploit is based on the fact that to sync the Cosmos SDK state and the EVM one, we rely on the `stateDB.Commit()` method. When we call this method, we iterate though all the `dirtyStorage` and, if and only if it is different than the `originStorage`, we set the new state. Setting the new state means we update the Cosmos SDK KVStore. If a contract storage state that is the same before and after a transaction, but is changed during the transaction and can call an external contract after the change, it can be exploited to make the transaction similar to non-atomic. The vulnerability is critical since this could lead to drain of funds through creative SC interactions. The issue has been patched in versions >=V17.0.0.
CVE-2022-36025	Critical	2022-09-24	No exploit published	No public exploit	Besu is a Java-based Ethereum client. In versions newer than 22.1.3 and prior to 22.7.1, Besu is subject to an Incorrect Conversion between Numeric Types. An error in 32 bit signed and unsigned types in the calculation of available gas in the CALL operations (including DELEGATECALL) results in incorrect gas being passed into called contracts and incorrect gas being returned after call execution. Where the amount of gas makes a difference in the success or failure, or if the gas is a negative 64 bit value, the execution will result in a different state root than expected, resulting in a consensus failure in networks with multiple EVM implementations. In networks with a single EVM implementation this can be used to execute with significantly more gas than then transaction requested, possibly exceeding gas limitations. This issue is patched in version 22.7.1. As a workaround, reverting to version 22.1.3 or earlier will prevent incorrect execution.
CVE-2021-41153	Critical	2021-10-18	Not applicable	No public exploit	The evm crate is a pure Rust implementation of Ethereum Virtual Machine. In `evm` crate `< 0.31.0`, `JUMPI` opcode's condition is checked after the destination validity check. However, according to Geth and OpenEthereum, the condition check should happen before the destination validity check. This is a high severity security advisory if you use `evm` crate for Ethereum mainnet. In this case, you should update your library dependency immediately to on or after `0.31.0`. This is a low severity security advisory if you use `evm` crate in Frontier or in a standalone blockchain, because there's no security exploit possible with this advisory. It is not recommended to update to on or after `0.31.0` until all the normal chain upgrade preparations have been done. If you use Frontier or other `pallet-evm` based Substrate blockchain, please ensure to update your `spec_version` before updating this. For other blockchains, please make sure to follow a hard-fork process before you update this.

CVE

Severity

Published▾

Status

Exploitation

Description

CVE-2025-55705

Critical

2026-01-22

Not applicable

No public exploit

This vulnerability occurs when the system permits multiple simultaneous connections to the backend using the same charging station ID. This can result in unauthorized access, data inconsistency, or potential manipulation of charging sessions. The lack of proper session management and expiration control allows attackers to exploit this weakness by reusing valid charging station IDs to establish multiple sessions concurrently.

CVE-2025-54816

Critical

2026-01-22

Not applicable

No public exploit

This vulnerability occurs when a WebSocket endpoint does not enforce proper authentication mechanisms, allowing unauthorized users to establish connections. As a result, attackers can exploit this weakness to gain unauthorized access to sensitive data or perform unauthorized actions. Given that no authentication is required, this can lead to privilege escalation and potentially compromise the security of the entire system.

CVE-2024-32644

Critical

2024-04-19

Not applicable

No public exploit

Evmos is a scalable, high-throughput Proof-of-Stake EVM blockchain that is fully compatible and interoperable with Ethereum. Prior to 17.0.0, there is a way to mint arbitrary tokens due to the possibility to have two different states not in sync during the execution of a transaction. The exploit is based on the fact that to sync the Cosmos SDK state and the EVM one, we rely on the `stateDB.Commit()` method. When we call this method, we iterate though all the `dirtyStorage` and, **if and only if** it is different than the `originStorage`, we set the new state. Setting the new state means we update the Cosmos SDK KVStore. If a contract storage state that is the same before and after a transaction, but is changed during the transaction and can call an external contract after the change, it can be exploited to make the transaction similar to non-atomic. The vulnerability is **critical** since this could lead to drain of funds through creative SC interactions. The issue has been patched in versions >=V17.0.0.

CVE-2022-36025

Critical

2022-09-24

No exploit published

No public exploit

Besu is a Java-based Ethereum client. In versions newer than 22.1.3 and prior to 22.7.1, Besu is subject to an Incorrect Conversion between Numeric Types. An error in 32 bit signed and unsigned types in the calculation of available gas in the CALL operations (including DELEGATECALL) results in incorrect gas being passed into called contracts and incorrect gas being returned after call execution. Where the amount of gas makes a difference in the success or failure, or if the gas is a negative 64 bit value, the execution will result in a different state root than expected, resulting in a consensus failure in networks with multiple EVM implementations. In networks with a single EVM implementation this can be used to execute with significantly more gas than then transaction requested, possibly exceeding gas limitations. This issue is patched in version 22.7.1. As a workaround, reverting to version 22.1.3 or earlier will prevent incorrect execution.

CVE-2021-41153

Critical

2021-10-18

Not applicable

No public exploit

The evm crate is a pure Rust implementation of Ethereum Virtual Machine. In `evm` crate `< 0.31.0`, `JUMPI` opcode's condition is checked after the destination validity check. However, according to Geth and OpenEthereum, the condition check should happen before the destination validity check. This is a **high** severity security advisory if you use `evm` crate for Ethereum mainnet. In this case, you should update your library dependency immediately to on or after `0.31.0`. This is a **low** severity security advisory if you use `evm` crate in Frontier or in a standalone blockchain, because there's no security exploit possible with this advisory. It is **not** recommended to update to on or after `0.31.0` until all the normal chain upgrade preparations have been done. If you use Frontier or other `pallet-evm` based Substrate blockchain, please ensure to update your `spec_version` before updating this. For other blockchains, please make sure to follow a hard-fork process before you update this.