Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
20 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Impact Through a flaw in the ECIES cryptography implementation, an attacker may be able to extract bits of the p2p node key. Patches The issue is resolved in the v1.16.9 and v1.17.0 releases of Geth. We recommend rotating the node key after applying the upgrade, which can be done by removing the file <datadir/geth/nodekey before starting Geth. Credit The issue was reported as a public pull request to go-ethereum by @fengjian.
Recommended action: Upgrade to 1.16.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A vulnerable node can be forced to shutdown/crash using a specially crafted message. More details to be released later. Patches The problem is resolved in the v1.16.9 and v1.17.0 releases of Geth. Credit This issue was reported to the Ethereum Foundation Bug Bounty Program by Waleed Ahmed from vulsight.com
Recommended action: Upgrade to 1.16.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An attacker can cause high memory usage by sending a specially-crafted p2p message. More details to be released later. Patches The issue is resolved in the v1.17.0 release. Credit This issue was reported to the Ethereum Foundation Bug Bounty Program by @revofusion
Recommended action: Upgrade to 1.17.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An attacker can cause high CPU usage by sending a specially crafted p2p message. More details to be released later. Credit This issue was reported to the Ethereum Foundation Bug Bounty Program by @Yenya030
Recommended action: Upgrade to 1.16.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A vulnerable node can be forced to shutdown/crash using a specially crafted message. More details to be released later. Credit This issue was reported to the Ethereum Foundation Bug Bounty Program by DELENE TCHIO ROMUALD.
Recommended action: Upgrade to 1.16.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/ethereum/go-ethereum >= 1.14.0, < 1.14.13
Fixed in
1.14.13· Vendor fix available
Issue
Impact A vulnerable node can be forced to shutdown/crash using a specially crafted message. During the peer-to-peer connection handshake, a shared secret key is computed. The implementation did not verify whether the EC public key provided by the remote party is a valid point on the secp256k1 curve. By simply sending an all-zero public key, a crash could be induced due to unexpected results from the handshake. The issue was fixed by adding a curve point validity check in https://github.com/ethereum/go-ethereum/commit/159fb1a1db551c544978dc16a5568a4730b4abf3 Patches A fix has been included in geth version 1.14.13 and onwards. Workarounds Unfortunately, no workaround is available. Credits This issue was originally reported to Polygon Security by David Matosse (@iam-ned).
Recommended action: Upgrade to 1.14.13 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A vulnerable node can be made to consume very large amounts of memory when handling specially crafted p2p messages sent from an attacker node. In order to carry out the attack, the attacker establishes a peer connections to the victim, and sends a malicious GetBlockHeadersRequest message with a count of 0, using the ETH protocol. In descendants := chain.GetHeadersFrom(num+count-1, count-1), the value of count-1 is passed to the function GetHeadersFrom(number, count uint64) as parameter count. Due to integer overflow, UINT64MAX value is then passed as the count argument to function GetHeadersFrom(number, count uint64). This allows an attacker to bypass maxHeadersServe and request all headers from the latest block back to the genesis block. Patches The fix has been included in geth version 1.13.15 and onwards. The vulnerability was patched in: https://github.com/ethereum/go-ethereum/pull/29534 Workarounds No workarounds have been made public. References No more information is…
Recommended action: Upgrade to 1.13.15 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/ethereum/go-ethereum < 1.12.1-stable
Fixed in
1.12.1-stable· Vendor fix available
Issue
Impact A vulnerable node, can be made to consume unbounded amounts of memory when handling specially crafted p2p messages sent from an attacker node. Details The p2p handler spawned a new goroutine to respond to ping requests. By flooding a node with ping requests, an unbounded number of goroutines can be created, leading to resource exhaustion and potentially crash due to OOM. Patches The fix is included in geth version 1.12.1-stable, i.e, 1.12.2-unstable and onwards. Fixed by https://github.com/ethereum/go-ethereum/pull/27887 Workarounds No known workarounds. Credits This bug was reported by Patrick McHardy and reported via bounty@ethereum.org. References
Recommended action: Upgrade to 1.12.1-stable (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact 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. Patches The following PR addresses the problem: https://github.com/ethereum/go-ethereum/pull/24507 Workarounds Aside from applying the PR linked above, setting loglevel to default level (INFO) makes the node not vulnerable to this attack. Credits This bug was reported by nrv via bounty@ethereum.org, who has gracefully requested that the bounty rewards be donated to Médecins sans frontières. For more information If you have any questions or comments about this advisory: Open an issue in go-ethereum
Recommended action: Upgrade to 1.10.17 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
The GetBlockHeadersMsg handler in the LES protocol implementation in Go Ethereum (aka geth) before 1.8.11 may lead to an access violation because of an integer signedness error for the array index, which allows attackers to launch a Denial of Service attack by sending a packet with a -1 query.Skip value. The vulnerable remote node would be crashed by such an attack immediately, aka the EPoD (Ethereum Packet of Death) issue. Specific Go Packages Affected github.com/ethereum/go-ethereum/les
Recommended action: Upgrade to 1.8.11 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A vulnerable node is susceptible to crash when processing a maliciously crafted message from a peer, via the snap/1 protocol. The crash can be triggered by sending a malicious snap/1 GetTrieNodes package. Details On September 21, 2021, geth-team member Gary Rong (@rjl493456442) found a way to crash the snap request handler . By using this vulnerability, a peer connected on the snap/1 protocol could cause a vulnerable node to crash with a panic. In the trie.TryGetNode implementation, if the requested path is reached, the associated node will be returned. However the nilness is not checked there. More specifically the origNode can be nil(e.g. the child of fullnode) and system can panic at line hash, = origNode.cache(). When investigating this, @holiman tried to find it via fuzzing, which uncovered a second crasher, also related to the snap GetTrieNodes package. If the caller requests a storage trie: The code assumes that snap.Account returns either a non-nil response unless…
Recommended action: Upgrade to 1.10.9 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/ethereum/go-ethereum >= 1.10.0, < 1.10.8
Fixed in
1.10.8· Vendor fix available
Issue
Impact A vulnerability in the Geth EVM could cause a node to reject the canonical chain. Description A memory-corruption bug within the EVM can cause a consensus error, where vulnerable nodes obtain a different stateRoot when processing a maliciously crafted transaction. This, in turn, would lead to the chain being split in two forks. All Geth versions supporting the London hard fork are vulnerable (which predates London), so all users should update. This bug was exploited on Mainnet at block 13107518, leading to a minority chain split. Patches A patch is included in the v1.10.8 release. The exact patch to fix the issue is contained within this commit Workarounds No workarounds exist, save to update and/or apply the patch commit. References. Post-mortem write-up. Credits The bug was found by @guidovranken (working for Sentnl during an audit of the Telos EVM) and reported via bounty@ethereum.org. For more information If you have any questions or comments about this advisory: Open an…
Recommended action: Upgrade to 1.10.8 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
cmd/evm/runner.go in Go Ethereum (aka geth) allows attackers to cause a denial of service (SEGV) via crafted bytecode. Specific Go Packages Affected github.com/ethereum/go-ethereum/cmd/evm
Recommended action: Upgrade to 1.8.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/ethereum/go-ethereum >= 1.9.4, < 1.9.20
Fixed in
1.9.20· Vendor fix available
Issue
Impact A consensus-vulnerability in Geth could cause a chain split, where vulnerable versions refuse to accept the canonical chain. Description A flaw was repoted at 2020-08-11 by John Youngseok Yang (Software Platform Lab), where a particular sequence of transactions could cause a consensus failure. - Tx 1: - sender invokes caller. - caller invokes 0xaa. 0xaa has 3 wei, does a self-destruct-to-self - caller does a 1 wei -call to 0xaa, who thereby has 1 wei (the code in 0xaa still executed, since the tx is still ongoing, but doesn't redo the selfdestruct, it takes a different path if callvalue is non-zero) - Tx 2: - sender does a 5-wei call to 0xaa. No exec (since no code). In geth, the result would be that 0xaa had 6 wei, whereas OE reported (correctly) 5 wei. Furthermore, in geth, if the second tx was not executed, the 0xaa would be destructed, resulting in 0 wei. Thus obviously wrong. It was determined that the root cause was this commit from this PR. The semantics of createObject…
Recommended action: Upgrade to 1.9.20 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A DoS vulnerability can make a LES server crash via malicious GetProofsV2 request from a connected LES client. Patches The vulnerability was patched in https://github.com/ethereum/go-ethereum/pull/21896. Workarounds This vulnerability only concerns users explicitly enabling les server; disabling les prevents the exploit. It can also be patched by manually applying the patch in https://github.com/ethereum/go-ethereum/pull/21896. For more information If you have any questions or comments about this advisory: Open an issue in go-ethereum Email us at security@ethereum.org
Recommended action: Upgrade to 1.9.25 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact Versions of Geth built with Go <1.15.5 or <1.14.12 are most likely affected by a critical DoS-related security vulnerability. The golang team has registered the underlying flaw as ‘CVE-2020-28362’. We recommend all users to rebuild (ideally v1.9.24) with Go 1.15.5 or 1.14.12, to avoid node crashes. Alternatively, if you are running binaries distributed via one of our official channels, we’re going to release v1.9.24 ourselves built with Go 1.15.5. Patches This is not an issue in go-ethereum, rebuilding an older version with Go 1.15.5 or 1.14.12 will suffice to address the vulnerability. Workarounds Rebuilding with Go 1.15.5 or 1.14.12 will suffice to address the vulnerability. References - https://blog.ethereum.org/2020/11/12/gethsecurityrelease/ - https://groups.google.com/g/golang-announce/c/NpBGTTmKzpM For more information If you have any questions or comments about this advisory: Open an issue in go-ethereum Email us at security@ethereum.org
Recommended action: Upgrade to 1.9.24 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/ethereum/go-ethereum >= 1.9.16, < 1.9.18
Fixed in
1.9.18· Vendor fix available
Issue
Impact Denial-of-service (crash) during block processing Details Affected versions suffer from a vulnerability which can be exploited through the MULMOD operation, by specifying a modulo of 0: mulmod(a,b,0), causing a panic in the underlying library. The crash was in the uint256 library, where a buffer underflowed. if d == 0, dLen remains 0 and https://github.com/holiman/uint256/blob/4ce82e695c10ddad57215bdbeafb68b8c5df2c30/uint256.go#L451 will try to access index [-1]. The uint256 library was first merged in this commit, on 2020-06-08. Exploiting this vulnerabilty would cause all vulnerable nodes to drop off the network. The issue was brought to our attention through a bug report, showing a panic occurring on sync from genesis on the Ropsten network. It was estimated that the least obvious way to fix this would be to merge the fix into uint256, make a new release of that library and then update the geth-dependency. - https://github.com/holiman/uint256/releases/tag/v1.1.1 was made…
Recommended action: Upgrade to 1.9.18 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/ethereum/go-ethereum >= 1.9.7, < 1.9.17
Fixed in
1.9.17· Vendor fix available
Issue
Impact This is a Consensus vulnerability, 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, - calls 0x00..04 with R as an argument, - 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. Patches No standalone patches have been made. Workarounds Upgrade to 1.9.17 or higher. References https://blog.ethereum.org/2020/11/12/gethsecurityrelease/ For more information If you have any questions or comments about this advisory: Open an issue in go-ethereum Email us at security@ethereum.org
Recommended action: Upgrade to 1.9.17 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An ethash mining DAG generation flaw in Geth 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. Patches This issue is also fixed as of 1.9.24. Thanks to @slavikus for bringing the issue to our attention and writing the fix. Workarounds This PR implements a patch: https://github.com/ethereum/go-ethereum/pull/21793 References https://blog.ethereum.org/2020/11/12/gethsecurityrelease/ For more information If you have any questions or comments about this advisory: Open an issue in go-ethereum Email us at security@ethereum.org
Recommended action: Upgrade to 1.9.24 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
In Go Ethereum (aka geth) before 1.8.14, TraceChain in eth/apitracer.go does not verify that the end block is after the start block. Specific Go Packages Affected github.com/ethereum/go-ethereum/eth
Recommended action: Upgrade to 1.8.14 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.