CVE-2025-53359: Ethereum Crate Signature Vulnerability

CVE-2025-53359 Overview

CVE-2025-53359 affects the ethereum crate for Rust, a library providing common Ethereum structs used by blockchain implementations. Prior to version v0.18.0, the crate enforced EIP-2 signature malleability checks only on legacy transactions. Transactions using EIP-2930, EIP-1559, and EIP-7702 formats bypassed the malleability check, creating a specification deviation [CWE-754]. An attacker who can submit or relay transactions could produce multiple valid signature encodings for the same transaction payload. On single-implementation blockchains the risk is limited, but on multi-implementation networks the divergence can cause consensus or transaction identity issues. The maintainers patched the flaw in version v0.18.0.

Critical Impact
Transactions in EIP-2930, EIP-1559, and EIP-7702 formats accept malleable signatures, allowing the same transaction to be encoded with distinct valid signatures and deviate from the Ethereum specification.

Affected Products

ethereum crate for Rust prior to v0.18.0
Downstream Rust projects consuming rust-ethereum/ethereum for transaction handling
Blockchain node or tooling implementations relying on the crate's TransactionSignature validation

Discovery Timeline

2025-07-02 - CVE-2025-53359 published to NVD
2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-53359

Vulnerability Analysis

The ethereum crate models Ethereum transaction types across legacy and typed transaction formats. EIP-2 requires that the s value of an ECDSA signature reside in the lower half of the secp256k1 curve order to prevent signature malleability. The crate enforced this invariant only when constructing legacy TransactionSignature values. Typed transactions introduced by EIP-2930 (access lists), EIP-1559 (fee market), and EIP-7702 (set code for EOAs) each defined their own signature containers without reusing the same validated TransactionSignature type. Callers could therefore build typed transactions carrying high-s signatures that a strict verifier would reject. The impact is a specification deviation rather than a direct compromise of confidentiality or code execution, but it can lead to transaction hash divergence and double-processing on multi-client networks.

Root Cause

The root cause is missing input validation on signature s values across the newer transaction types. The eip1559 and eip7702 modules defined independent transaction and signature structures instead of sharing the checked TransactionSignature from the legacy path, so the EIP-2 invariant was never enforced on those code paths.

Attack Vector

An attacker crafts a valid typed transaction, then flips the signature s value to n - s and negates parity, producing a second encoding with a different transaction hash for the same underlying operation. Software using the vulnerable crate accepts both encodings. Exploitation requires only the ability to submit or relay transactions over the network.

rust

// Security patch in src/transaction/eip1559.rs
// Reuses the validated TransactionSignature from eip2930
use rlp::{DecoderError, Rlp, RlpStream};
use sha3::{Digest, Keccak256};

use crate::Bytes;

pub use super::eip2930::{AccessList, TransactionAction, TransactionSignature};

Source: rust-ethereum/ethereum commit 2dd9d1d

The patch consolidates the signature type so all typed transactions maintain the EIP-2 invariant.

Detection Methods for CVE-2025-53359

Indicators of Compromise

Two distinct transaction hashes carrying identical sender, nonce, and payload but different signature s values.
Typed transactions (types 0x01, 0x02, 0x04) whose signature s value exceeds secp256k1n / 2.
Rejection logs from strict verifiers alongside acceptance logs from services built on the vulnerable crate.

Detection Strategies

Audit dependency manifests (Cargo.toml, Cargo.lock) for ethereum crate versions earlier than 0.18.0.
Instrument transaction ingestion pipelines to compute s and flag values greater than half the curve order for EIP-2930, EIP-1559, and EIP-7702 transactions.
Cross-check transaction hashes emitted by services against a reference client to detect divergence.

Monitoring Recommendations

Monitor mempool feeds for duplicate logical transactions with distinct hashes originating from the same sender and nonce.
Track error rates from downstream verifiers that enforce strict EIP-2 to identify upstream services still on vulnerable crate versions.
Alert on new deployments of Rust binaries pulling ethereum crate versions below 0.18.0 through software composition analysis tooling.

How to Mitigate CVE-2025-53359

Immediate Actions Required

Upgrade the ethereum crate dependency to v0.18.0 or later in all affected Rust projects.
Rebuild and redeploy downstream services, nodes, and tooling that link the vulnerable crate.
Review any custom transaction validation code to confirm it does not bypass the invariant now enforced by the crate.

Patch Information

The fix is delivered in ethereum crate v0.18.0. The consolidating change is tracked in pull request #67 and merged as commit 2dd9d1d5d0936ec7350093ff3a5a7169a349db77. Full details are published in GitHub Security Advisory GHSA-3w94-vq2x-v5wr.

Workarounds

Manually verify that each typed transaction's signature s value is less than or equal to secp256k1n / 2 before accepting it outside the crate.
Reject transactions whose recomputed hash differs from a reference client's hash for the same payload.
Restrict transaction submission paths to trusted relayers until upgrade is complete.

bash

# Update the ethereum crate to the patched release
cargo update -p ethereum --precise 0.18.0
cargo tree -i ethereum   # confirm no transitive pins remain below 0.18.0
cargo build --release