Remote DoS via ECIES Decryption Panic in Geth

Overview

In January 2026, the Geth team released a security fix addressing a DoS vulnerability in the ECIES decryption logic used in Ethereum p2p communication.

The issue is tracked as GHSA-mr7q-c9w9-wh4h and allows a remote peer to crash a Geth node by sending a specially crafted encrypted p2p message. The crash is caused by an out-of-bounds slice access during ECIES symmetric decryption, resulting in a runtime panic.

Vulnerability Summary:

• Impact: Remote DoS (node crash)
• Attack Vector: Ethereum p2p networking layer
• Severity: High (unauthenticated remote crash)
• Affected: Geth and downstream implementations utilizing the affected ECIES logic
• Fix: Corrected minimum-length validation before decryption
• Reporter: DELENE TCHIO ROMUALD (via the Ethereum Foundation Bug Bounty Program)

All Geth users are strongly recommended to upgrade. OP-Geth released a corresponding patched version as well.

Background: ECIES in Ethereum P2P

P2P handshake and encrypted messaging

Ethereum nodes communicate over a custom peer-to-peer protocol known as RLPx.

RLPx establishes encrypted peer-to-peer connections using an ECIES-based handshake over secp256k1.

ECIES message structure (simplified)

An ECIES ciphertext in Geth has the following logical structure:

ciphertext =
    ephemeral_public_key (65 bytes)
  || encrypted_message   (variable length)
  || mac                 (32 bytes)

The encrypted_message itself is expected to be:

encrypted_message =
    IV (blockSize bytes, AES = 16) || encrypted_payload

This implies a minimum required length for the encrypted message part.

Trust boundary

Importantly, all ECIES ciphertexts are fully attacker-controlled input:

• Any remote peer can send ECIES-encrypted messages
• The receiver must treat all ciphertexts as untrusted and potentially malformed.
• Length validation is therefore security-critical

As a result, any unchecked assumption in ECIES parsing or decryption code can directly translate into a remote denial-of-service condition.

Root Cause Analysis

The vulnerable code path

The vulnerability stems from an out-of-bounds slice access in the ECIES symmetric decryption helper:

func symDecrypt(params *ECIESParams, key, ct []byte) ([]byte, error) {
    c, _ := params.Cipher(key)
    ctr := cipher.NewCTR(c, ct[:params.BlockSize]) // ← panic here
    ...
}

This code assumes:

len(ct) >= params.BlockSize

However, this assumption was not enforced by the caller.

Incorrect length check

In PrivateKey.Decrypt, the pre-decryption length check was effectively:

len(ciphertext) >=
    ephemeralPubKeyLen (65)
  + macLen             (32)
  + 1                  // incorrect

This allowed ciphertexts where the encrypted message part was shorter than one AES block (16 bytes).

As a result:

• The malformed ciphertext passed validation
• symDecrypt was invoked
• ct[:params.BlockSize] caused a slice-out-of-bounds panic
• The node crashed

The fix replaces the incorrect + 1 check with:

+ params.BlockSize

ensuring the IV is always present.

Minimal Proof of Concept

To demonstrate the issue, we constructed a minimal PoC that:

• Uses a valid ECIES ephemeral key
• Computes a correct MAC
• Intentionally sets the encrypted message length to less than 16 bytes

This is sufficient to trigger the panic on vulnerable versions. The full PoC source code is available at: https://github.com/qzhodl/CVE-2026-22862

Key Takeaways

This vulnerability illustrates several important lessons for client and protocol developers:

Length checks must match downstream assumptions

Every slice operation (x[:N]) encodes a hidden precondition:

len(x) >= N

If that assumption is enforced in a different function or layer, the validation must be exact, not approximate.

Cryptographic correctness ≠ memory safety

Even though:

• The ECIES math was correct
• The MAC was verified
• The ciphertext was “cryptographically valid”

the implementation still crashed due to a simple bounds error.

Panic as a DoS Vector

In network-facing code:

• A panic is equivalent to a remote crash
• All panics must be treated as potential DoS vulnerabilities

Defensive programming is especially critical in cryptographic and parsing code.

If you have any questions, please visit our community channels for support and more information.

Discord | Twitter | Telegram | Website | Blog