Filtered by vendor Ethereum
Subscribe
Total
33 CVE
CVE | Vendors | Products | Updated | CVSS v2 | CVSS v3 |
---|---|---|---|---|---|
CVE-2023-36980 | 1 Ethereum | 1 Blockchain | 2024-09-26 | N/A | 5.3 MEDIUM |
An issue in Ethereum Blockchain v0.1.1+commit.6ff4cd6 cause the balance to be zeroed out when the value of betsize+casino.balance exceeds the threshold. | |||||
CVE-2023-42319 | 1 Ethereum | 1 Go Ethereum | 2024-09-13 | N/A | 7.5 HIGH |
Geth (aka go-ethereum) through 1.13.4, when --http --graphql is used, allows remote attackers to cause a denial of service (memory consumption and daemon hang) via a crafted GraphQL query. NOTE: the vendor's position is that the "graphql endpoint [is not] designed to withstand attacks by hostile clients, nor handle huge amounts of clients/traffic. | |||||
CVE-2022-37450 | 1 Ethereum | 1 Go Ethereum | 2024-02-04 | N/A | 5.9 MEDIUM |
Go Ethereum (aka geth) through 1.10.21 allows attackers to increase rewards by mining blocks in certain situations, and using a manipulation of time-difference values to achieve replacement of main-chain blocks, aka Riskless Uncle Making (RUM), as exploited in the wild in 2020 through 2022. | |||||
CVE-2022-1930 | 1 Ethereum | 1 Eth-account | 2024-02-04 | N/A | 7.5 HIGH |
An exponential ReDoS (Regular Expression Denial of Service) can be triggered in the eth-account PyPI package, when an attacker is able to supply arbitrary input to the encode_structured_data method | |||||
CVE-2022-23327 | 1 Ethereum | 1 Go Ethereum | 2024-02-04 | 5.0 MEDIUM | 7.5 HIGH |
A design flaw in Go-Ethereum 1.10.12 and older versions allows an attacker node to send 5120 future transactions with a high gas price in one message, which can purge all of pending transactions in a victim node's memory pool, causing a denial of service (DoS). | |||||
CVE-2022-29177 | 1 Ethereum | 1 Go Ethereum | 2024-02-04 | 4.3 MEDIUM | 5.9 MEDIUM |
Go Ethereum is the official Golang implementation of the Ethereum protocol. Prior to version 1.10.17, a vulnerable node, if configured to use high verbosity logging, can be made to crash when handling specially crafted p2p messages sent from an attacker node. Version 1.10.17 contains a patch that addresses the problem. As a workaround, setting loglevel to default level (`INFO`) makes the node not vulnerable to this attack. | |||||
CVE-2021-42219 | 1 Ethereum | 1 Go Ethereum | 2024-02-04 | 5.0 MEDIUM | 7.5 HIGH |
Go-Ethereum v1.10.9 was discovered to contain an issue which allows attackers to cause a denial of service (DoS) via sending an excessive amount of messages to a node. This is caused by missing memory in the component /ethash/algorithm.go. | |||||
CVE-2022-23328 | 1 Ethereum | 1 Go Ethereum | 2024-02-04 | 5.0 MEDIUM | 7.5 HIGH |
A design flaw in all versions of Go-Ethereum allows an attacker node to send 5120 pending transactions of a high gas price from one account that all fully spend the full balance of the account to a victim Geth node, which can purge all of pending transactions in a victim node's memory pool and then occupy the memory pool to prevent new transactions from entering the pool, resulting in a denial of service (DoS). | |||||
CVE-2021-43668 | 1 Ethereum | 1 Go Ethereum | 2024-02-04 | 2.1 LOW | 5.5 MEDIUM |
Go-Ethereum 1.10.9 nodes crash (denial of service) after receiving a serial of messages and cannot be recovered. They will crash with "runtime error: invalid memory address or nil pointer dereference" and arise a SEGV signal. | |||||
CVE-2021-41173 | 1 Ethereum | 1 Go Ethereum | 2024-02-04 | 3.5 LOW | 5.7 MEDIUM |
Go Ethereum is the official Golang implementation of the Ethereum protocol. Prior to version 1.10.9, a vulnerable node is susceptible to crash when processing a maliciously crafted message from a peer. Version v1.10.9 contains patches to the vulnerability. There are no known workarounds aside from upgrading. | |||||
CVE-2021-39137 | 1 Ethereum | 1 Go Ethereum | 2024-02-04 | 5.0 MEDIUM | 7.5 HIGH |
go-ethereum is the official Go implementation of the Ethereum protocol. In affected versions a consensus-vulnerability in go-ethereum (Geth) could cause a chain split, where vulnerable versions refuse to accept the canonical chain. Further details about the vulnerability will be disclosed at a later date. A patch is included in the upcoming `v1.10.8` release. No workaround are available. | |||||
CVE-2020-26800 | 1 Ethereum | 1 Aleth | 2024-02-04 | 4.3 MEDIUM | 5.5 MEDIUM |
A stack overflow vulnerability in Aleth Ethereum C++ client version <= 1.8.0 using a specially crafted a config.json file may result in a denial of service. | |||||
CVE-2020-26265 | 1 Ethereum | 1 Go Ethereum | 2024-02-04 | 3.5 LOW | 5.3 MEDIUM |
Go Ethereum, or "Geth", is the official Golang implementation of the Ethereum protocol. In Geth from version 1.9.4 and before version 1.9.20 a consensus-vulnerability could cause a chain split, where vulnerable versions refuse to accept the canonical chain. The fix was included in the Paragade release version 1.9.20. No individual workaround patches have been made -- all users are recommended to upgrade to a newer version. | |||||
CVE-2020-26264 | 1 Ethereum | 1 Go Ethereum | 2024-02-04 | 4.0 MEDIUM | 6.5 MEDIUM |
Go Ethereum, or "Geth", is the official Golang implementation of the Ethereum protocol. In Geth before version 1.9.25 a denial-of-service vulnerability can make a LES server crash via malicious GetProofsV2 request from a connected LES client. This vulnerability only concerns users explicitly enabling les server; disabling les prevents the exploit. The vulnerability was patched in version 1.9.25. | |||||
CVE-2020-26241 | 1 Ethereum | 1 Go Ethereum | 2024-02-04 | 5.5 MEDIUM | 7.1 HIGH |
Go Ethereum, or "Geth", is the official Golang implementation of the Ethereum protocol. This is a Consensus vulnerability in Geth before version 1.9.17 which can be used to cause a chain-split where vulnerable nodes reject the canonical chain. Geth's pre-compiled dataCopy (at 0x00...04) contract did a shallow copy on invocation. An attacker could deploy a contract that writes X to an EVM memory region R, then calls 0x00..04 with R as an argument, then overwrites R to Y, and finally invokes the RETURNDATACOPY opcode. When this contract is invoked, a consensus-compliant node would push X on the EVM stack, whereas Geth would push Y. This is fixed in version 1.9.17. | |||||
CVE-2020-26240 | 1 Ethereum | 1 Go Ethereum | 2024-02-04 | 5.0 MEDIUM | 7.5 HIGH |
Go Ethereum, or "Geth", is the official Golang implementation of the Ethereum protocol. An ethash mining DAG generation flaw in Geth before version 1.9.24 could cause miners to erroneously calculate PoW in an upcoming epoch (estimated early January, 2021). This happened on the ETC chain on 2020-11-06. This issue is relevant only for miners, non-mining nodes are unaffected. This issue is fixed as of 1.9.24 | |||||
CVE-2020-26242 | 1 Ethereum | 1 Go Ethereum | 2024-02-04 | 5.0 MEDIUM | 7.5 HIGH |
Go Ethereum, or "Geth", is the official Golang implementation of the Ethereum protocol. In Geth before version 1.9.18, there is a Denial-of-service (crash) during block processing. This is fixed in 1.9.18. | |||||
CVE-2017-14451 | 1 Ethereum | 1 Ethereum | 2024-02-04 | 7.5 HIGH | 10.0 CRITICAL |
An exploitable out-of-bounds read vulnerability exists in libevm (Ethereum Virtual Machine) of CPP-Ethereum. A specially crafted smart contract code can cause an out-of-bounds read which can subsequently trigger an out-of-bounds write resulting in remote code execution. An attacker can create/send malicious smart contract to trigger this vulnerability. | |||||
CVE-2018-15890 | 1 Ethereum | 1 Ethereumj | 2024-02-04 | 10.0 HIGH | 9.8 CRITICAL |
An issue was discovered in EthereumJ 1.8.2. There is Unsafe Deserialization in ois.readObject in mine/Ethash.java and decoder.readObject in crypto/ECKey.java. When a node syncs and mines a new block, arbitrary OS commands can be run on the server. | |||||
CVE-2018-20421 | 1 Ethereum | 1 Go Ethereum | 2024-02-04 | 5.0 MEDIUM | 7.5 HIGH |
Go Ethereum (aka geth) 1.8.19 allows attackers to cause a denial of service (memory consumption) by rewriting the length of a dynamic array in memory, and then writing data to a single memory location with a large index number, as demonstrated by use of "assembly { mstore }" followed by a "c[0xC800000] = 0xFF" assignment. |