“The Intriguing Mystery of Subgroup Verification in Besu: Explaining CVE-2025-30147”

Appreciation goes to Marius Van Der Wijden for developing the test case and statetest, and for assisting the Besu team in validating the issue. Furthermore, commendations to the Besu team, the EF security team, and Kevaundray Wedderburn. Additionally, gratitude to Justin Traglia, Marius Van Der Wijden, Benedikt Wagner, and Kevaundray Wedderburn for reviewing the content. Should you have further inquiries or comments, reach out to me on Twitter at @asanso

tl;dr: Besu Ethereum execution client version 25.2.2 encountered a consensus flaw associated with the EIP-196/EIP-197 precompiled contract management for the elliptic curve alt_bn128 (also known as bn254). The matter was rectified in release 25.3.0.
Access the complete CVE report.

N.B.: A portion of this article necessitates some understanding of elliptic curves (cryptography).

Introduction

The bn254 curve (also referred to as alt_bn128) serves as an elliptic curve utilized in Ethereum for cryptographic procedures. It facilitates processes such as elliptic curve cryptography, rendering it essential for numerous Ethereum functionalities. Prior to EIP-2537 and the latest Pectra update, bn254 was the exclusive pairing curve endorsed by the Ethereum Virtual Machine (EVM). Both EIP-196 and EIP-197 outline precompiled contracts for effective computations on this curve. For additional information regarding bn254, you may refer to this link.

A notable security weakness in elliptic curve cryptography is the invalid curve attack, initially proposed in the document “Differential fault attacks on elliptic curve cryptosystems”. This assault targets the use of points not residing on the accurate elliptic curve, potentially resulting in vulnerabilities within cryptographic protocols. For non-prime order curves (like those used in pairing-based cryptography and in G2G_2G2​ for bn254), it becomes particularly vital that the point is within the appropriate subgroup. If the point fails to belong to the designated subgroup, the cryptographic procedure may be influenced, potentially undermining the security of systems that depend on elliptic curve cryptography.

To ascertain if a point P is legitimate in elliptic curve cryptography, it must be confirmed that the point is situated on the curve and is part of the correct subgroup. This verification is especially crucial when the point P originates from an untrusted or possibly hostile source, as invalid or purposefully designed points can lead to security flaws. Below is pseudocode illustrating this procedure:

# Pseudocode for verifying if point P is valid
def is_valid_point(P):
    if not is_on_curve(P):    
        return False
    if not is_in_subgroup(P):
        return False
    return True

Subgroup membership verifications

As noted previously, when handling any point of uncertain origin, it is essential to ascertain that it belongs to the appropriate subgroup, in addition to confirming that the point is situated on the correct curve. For bn254, this validation is only required for G2G_2G2​, since G1G_1G1​ is of prime order. A simple technique to verify membership in $G$ is to multiply a point by $r$, where $r$ represents the cofactor of the curve, which is the ratio of the curve’s order to the base point’s order.

Nevertheless, this method can be prohibitive in practice due to the substantial size of the prime $r$, particularly for G2G_2G2​. In 2021, Scott introduced a quicker method for subgroup membership verification on BLS12 curves employing an easily computable endomorphism, expediting the process by 2×, 4×, and 4× for various groups (this approach is detailed in EIP-2537 for efficient subgroup verifications, as outlined in this document).
Subsequently, Dai et al. extended Scott’s method to accommodate a wider variety of curves, including BN curves, diminishing the number of operations necessary for subgroup membership checks. In some instances, the method can be almost cost-free. Koshelev also presented a technique for non-pairing-friendly curves utilizing the Tate pairing, which was ultimately
“““html
further expanded to pairing-friendly curves.

The Genuine Slim Shady

As illustrated in the timeline at the conclusion of this article, we received a notification regarding a flaw impacting Pectra EIP-2537 on Besu, submitted through the Pectra Audit Competition. We are only briefly addressing that concern here, in case the initial reporter wishes to delve into it further. This article specifically addresses the BN254 EIP-196/EIP-197 vulnerability.

The initial reporter noted that, in Besu, the is_in_subgroup validation was carried out prior to the is_on_curve verification. Here’s an example of how that could appear:

# Pseudocode for validating point P
def is_valid_point(P):
    if not is_in_subgroup(P):    
        if not is_on_curve(P):
            return False  
        return False
    return True

Fascinated by the previously mentioned matter on the BLS curve, we opted to examine the Besu code for the BN curve. To my utter astonishment, we discovered something akin to this:

# Pseudocode for validating point P
def is_valid_point(P):
    if not is_in_subgroup(P):    
        return False
    return True

Hold on, what? Where is the is_on_curve validation? Precisely—there’s none!!!

Now, to potentially circumvent the is_valid_point function, all one would need is to present a point that exists within the appropriate subgroup but isn’t genuinely on the curve.

But hold on—is that even feasible?

Indeed, but solely for specific, meticulously selected curves. In particular, when two curves are isomorphic, they possess the identical group structure, signifying that you could fabricate a point from the isomorphic curve that meets subgroup requirements but does not reside on the desired curve.

Clever, right?

Did you mention isomorphism?

You can bypass this section if you’re uninterested in the specifics—we’re about to delve a little deeper into the mathematics.

Let Fqmathbb{F}_qFq​ be a finite field with a characteristic that differs from 2 and 3, meaning q=pfq = p^fq=pf for some prime $p\ge 5$ and integer $f\ge 1$. We examine elliptic curves $E$ over Fqmathbb{F}_qFq​ defined by the concise Weierstraß equation:

where $A$ and $B$ are constants that fulfill 4A3+27B2≠04A^3 + 27B^2 neq 04A3+27B2=0.^[This restriction guarantees the curve is non-singular; should it be disregarded, the equation would depict a singular point devoid of a well-defined tangent, hindering meaningful self-addition. In such scenarios, the entity is not technically an elliptic curve.]

Curve Isomorphisms

Two elliptic curves are deemed isomorphic^[To leverage the vulnerabilities mentioned here, we genuinely desire isomorphic curves, not solely isogenous curves.] if they can be connected via an affine alteration of variables. Such modifications maintain the group structure and assure that point addition stays coherent. It can be demonstrated that the sole feasible transformations between two curves in short Weierstraß form take the following shape:

for some nonzero e∈ “““html Fqe in mathbb{F}_qe∈Fq​. Utilizing this alteration on the curve equation yields:

The $j$-invariant of a curve is characterized as:

Each component of Fqmathbb{F}_qFq​ can be a potential $j$-invariant.^[Both BLS and BN curves exhibit a j-invariant corresponding to 0, which is truly unique.] When two elliptic curves possess the identical $j$-invariant, they are either isomorphic (in the previously mentioned sense) or they are twists of one another.^[We will not delve into twists here, as they are irrelevant to this context.]

Exploitability

At this juncture, the remaining task is to formulate a suitable point on a meticulously selected curve, and voilà—le jeu est fait.

You may experiment with the test vector via this link and have fun.

Conclusion

In this article, we examined the vulnerability present in Besu’s execution of elliptic curve verifications. This defect, if leveraged, could permit an assailant to forge a point that passes subgroup membership tests but does not actually reside on the valid curve. The Besu developers have subsequently rectified this concern in release 25.3.0. While the problem was confined to Besu and did not impact other clients, such discrepancies elevate significant issues for multi-client frameworks like Ethereum. A misalignment in cryptographic verifications among clients can lead to divergent actions—where one client endorses a transaction or block that another dismisses. This type of inconsistency can jeopardize consensus and erode confidence in the network’s uniformity, particularly when subtle errors go unnoticed across various implementations. This incident underscores the necessity for thorough testing and strong security protocols—especially within blockchain environments, where even trivial cryptographic errors can cascade into considerable systemic weaknesses. Initiatives such as the Pectra audit competition play an essential role in proactively uncovering these problems before they transition to production. By promoting diverse scrutiny of the code, such endeavors enhance the overall stability of the ecosystem.

Timeline

• 15-03-2025 – Issue impacting Pectra EIP-2537 on Besu reported through the Pectra Audit Competition.
• 17-03-2025 – Identified and communicated the EIP-196/EIP-197 concern to the Besu team.
• 17-03-2025 – Marius Van Der Wijden established a test case and statetest to replicate the issue.
• 17-03-2025 – The Besu team swiftly recognized and resolved the issue.