Overview 10 matches · 0 in Waratek scope · 0 protected · 0 exploited · 0 CISA KEV · 0 public PoC · 0 EPSS ≥ 0.5
10matches
0in Waratek scope0.0%
0protected0.0%
0exploited0.0%
0CISA KEV0.0%
0public PoC0.0%
0EPSS ≥ 0.50.0%
Protected by Waratek
0
0.0%
Rule in development
0
0.0%
Mitigation candidate
0
0.0%
No exploit published
0
0.0%
Outside Waratek scope
0
0.0%
Not applicable
10
100.0%
Withdrawn CVE
0
0.0%
blocked by ARMR today
0
0.0%
partly blocked
0
0.0%
not blocked
10
100.0%
not established
0
0.0%
unrecorded
0
0.0%
Exploited
0
0.0%
Working exploit published
0
0.0%
Proof of concept only
2
20.0%
Forecast only
0
0.0%
No public exploit
8
80.0%
split by
peak 4 / year
20181
Not applicable1
High1
not blocked1
No public exploit1
20190
20200
20211
Not applicable1
High1
not blocked1
No public exploit1
20223
Not applicable3
High3
not blocked3
Proof of concept only1
No public exploit2
20230
20244
Not applicable4
High4
not blocked4
Proof of concept only1
No public exploit3
20250
20261
Not applicable1
High1
not blocked1
No public exploit1
201820192020202120222023202420252026
| CVE | Severity | Published▾ | Status | Exploitation | Description |
|---|---|---|---|---|---|
| CVE-2025-53968 | High | 2026-01-22 | Not applicable | No public exploit | This vulnerability arises because there are no limitations on the number of authentication attempts a user can make. An attacker can exploit this weakness by continuously sending authentication requests, leading to a denial-of-service (DoS) condition. This can overwhelm the authentication system, rendering it unavailable to legitimate users and potentially causing service disruption. This can also allow attackers to conduct brute-force attacks to gain unauthorized access. |
| CVE-2024-39696 | High | 2024-07-05 | Not applicable | No public exploit | Evmos is a decentralized Ethereum Virtual Machine chain on the Cosmos Network. Prior to version 19.0.0, a user can create a vesting account with a 3rd party account (EOA or contract) as funder. Then, this user can create an authorization for the contract.CallerAddress, this is the authorization checked in the code. But the funds are taken from the funder address provided in the message. Consequently, the user can fund a vesting account with a 3rd party account without its permission. The funder address can be any address, so this vulnerability can be used to drain all the accounts in the chain. The issue has been patched in version 19.0.0. |
| CVE-2024-37158 | High | 2024-06-17 | Not applicable | No public exploit | Evmos is the Ethereum Virtual Machine (EVM) Hub on the Cosmos Network. Preliminary checks on actions computed by the clawback vesting accounts are performed in the ante handler. Evmos core, implements two different ante handlers: one for Cosmos transactions and one for Ethereum transactions. Checks performed on the two implementation are different. The vulnerability discovered allowed a clawback account to bypass Cosmos ante handler checks by sending an Ethereum transaction targeting a precompile used to interact with a Cosmos SDK module. This vulnerability is fixed in 18.0.0. |
| CVE-2024-37153 | High | 2024-06-06 | Not applicable | Proof of concept only | Evmos is the Ethereum Virtual Machine (EVM) Hub on the Cosmos Network. There is an issue with how to liquid stake using Safe which itself is a contract. The bug only appears when there is a local state change together with an ICS20 transfer in the same function and uses the contract's balance, that is using the contract address as the sender parameter in an ICS20 transfer using the ICS20 precompile. This is in essence the "infinite money glitch" allowing contracts to double the supply of Evmos after each transaction.The issue has been patched in versions >=V18.1.0. |
| CVE-2024-21629 | High | 2024-01-02 | Not applicable | No public exploit | Rust EVM is an Ethereum Virtual Machine interpreter. In `rust-evm`, a feature called `record_external_operation` was introduced, allowing library users to record custom gas changes. This feature can have some bogus interactions with the call stack. In particular, during finalization of a `CREATE` or `CREATE2`, in the case that 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. This causes smart contracts able 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. The issue is patched in release 0.41.1. No known workarounds are available. |
| CVE-2022-39354 | High | 2022-10-25 | Not applicable | No public exploit | SputnikVM, also called evm, is a Rust implementation of Ethereum Virtual Machine. A custom stateful precompile can use the `is_static` parameter to determine if the call is executed in a static context (via `STATICCALL`), and thus decide if stateful operations should be done. Prior to version 0.36.0, the passed `is_static` parameter was incorrect -- it was only set to `true` if the call came from a direct `STATICCALL` opcode. However, once a static call context is entered, it should stay static. The issue only impacts custom precompiles that actually uses `is_static`. For those affected, the issue can lead to possible incorrect state transitions. Version 0.36.0 contains a patch. There are no known workarounds. |
| CVE-2022-35936 | High | 2022-08-05 | Not applicable | Proof of concept only | Ethermint is an Ethereum library. In Ethermint running versions before `v0.17.2`, the contract `selfdestruct` invocation permanently removes the corresponding bytecode from the internal database storage. However, due to a bug in the `DeleteAccount`function, all contracts that used the identical bytecode (i.e shared the same `CodeHash`) will also stop working once one contract invokes `selfdestruct`, even though the other contracts did not invoke the `selfdestruct` OPCODE. This vulnerability has been patched in Ethermint version v0.18.0. The patch has state machine-breaking changes for applications using Ethermint, so a coordinated upgrade procedure is required. A workaround is available. If a contract is subject to DoS due to this issue, the user can redeploy the same contract, i.e. with identical bytecode, so that the original contract's code is recovered. The new contract deployment restores the `bytecode hash -> bytecode` entry in the internal state. |
| CVE-2022-24738 | High | 2022-03-07 | Not applicable | No public exploit | Evmos is the Ethereum Virtual Machine (EVM) Hub on the Cosmos Network. In versions of evmos prior to 2.0.1 attackers are able to drain unclaimed funds from user addresses. To do this an attacker must create a new chain which does not enforce signature verification and connects it to the target evmos instance. The attacker can use this joined chain to transfer unclaimed funds. Users are advised to upgrade. There are no known workarounds for this issue. |
| CVE-2021-43839 | High | 2021-12-21 | Not applicable | No public exploit | Cronos is a commercial implementation of a blockchain. In Cronos nodes running versions before v0.6.5, it is possible to take transaction fees from Cosmos SDK's FeeCollector for the current block by sending a custom crafted MsgEthereumTx. This problem has been patched in Cronos v0.6.5. There are no tested workarounds. All validator node operators are recommended to upgrade to Cronos v0.6.5 at their earliest possible convenience. |
| CVE-2018-18920 | High | 2018-11-12 | Not applicable | No public exploit | Py-EVM v0.2.0-alpha.33 allows attackers to make a vm.execute_bytecode call that triggers computation._stack.values with '"stack": [100, 100, 0]' where b'\x' was expected, resulting in an execution failure because of an invalid opcode. This is reportedly related to "smart contracts can be executed indefinitely without gas being paid." |