CVE-2025-30147 is a high-severity vulnerability affecting Hyperledger Besu's native cryptographic library component, besu-native, specifically versions from 0.9.0 up to but not including 1.3.0. Hyperledger Besu is an Ethereum client widely used in enterprise blockchain deployments. The vulnerability arises from a missing cryptographic verification step in the implementation of certain elliptic curve (EC) precompiles: ALTBN128_ADD (0x06), ALTBN128_MUL (0x07), and ALTBN128_PAIRING (0x08). These precompiles are critical for cryptographic operations on the bn254 curve, used in zero-knowledge proofs and other advanced cryptographic protocols within Ethereum. The besu-native library replaced an older, less performant cryptographic library with gnark-crypto's bn254 implementation starting in version 0.9.0. However, gnark-crypto at that time performed subgroup membership checks but did not verify that EC points were actually on the curve. This subtle but critical omission allowed crafted EC points that are in the correct subgroup but not on the curve to be accepted. Consequently, Besu could produce incorrect results when executing these precompiles, leading to consensus failures in the blockchain network. Such consensus bugs can cause network forks or invalid state transitions, which are particularly problematic for homogeneous Besu networks, as they may enshrine invalid blockchain states that patched clients cannot process correctly. The vulnerability was patched in besu-native 1.3.0 and Besu 25.3.0. As an interim mitigation, affected Besu versions can disable the native precompile implementation and revert to a pure Java implementation, which is slower but does not suffer from this consensus issue. The CVSS 4.0 score is 8.7 (high), reflecting the network attack vector, no required privileges or user interaction, and the high impact on integrity due to consensus failures. No known exploits are reported in the wild as of the publication date.

For European organizations utilizing Hyperledger Besu in their blockchain infrastructure, this vulnerability poses a significant risk to the integrity and reliability of their distributed ledger systems. Consensus failures can lead to network forks, invalid transaction states, and potential loss of trust in the blockchain data. This is especially critical for financial institutions, supply chain consortia, and public sector entities relying on Besu for transparent and tamper-evident record-keeping. The inability to correctly validate cryptographic operations may disrupt smart contract executions and zero-knowledge proof verifications, potentially halting business processes or causing incorrect contract outcomes. Moreover, homogeneous Besu networks in Europe could face difficulties in upgrading or patching nodes without risking chain splits or data inconsistencies. The performance trade-off when switching to the pure Java implementation may impact transaction throughput and latency, affecting service levels. While no active exploitation is reported, the high severity and fundamental nature of the cryptographic flaw necessitate urgent attention to avoid operational disruptions and maintain compliance with data integrity standards.

European organizations should prioritize upgrading to besu-native version 1.3.0 and Hyperledger Besu 25.3.0 or later, where the cryptographic checks have been correctly implemented. Until upgrades can be performed, disabling the native precompile implementation for altbn128 and reverting to the pure Java implementation is recommended to maintain consensus correctness, despite the performance penalty. Network operators should carefully coordinate upgrades across all nodes to prevent chain splits caused by mixed versions. Additionally, organizations should audit their blockchain states for inconsistencies that may have arisen from this vulnerability and consider replaying or reconciling transactions if invalid states are detected. Monitoring for updates from Hyperledger and related cryptographic libraries is essential to stay ahead of any emerging exploits. Implementing rigorous testing of blockchain consensus behavior after patching will help ensure network stability. Finally, organizations should review their cryptographic validation processes and consider integrating additional cryptographic verification layers or anomaly detection to catch malformed inputs that could exploit similar issues in the future.