Thanks to Marius Van Der Wijden for creating the test case and statetest, and for helping the Besu team confirm the issue. Also, kudos to the Besu team, the EF security team, and Kevaundray Wedderburn. Additionally, thanks to Yuxiang Qiu, Justin Traglia, Marius Van Der Wijden, Benedikt Wagner, and Kevaundray Wedderburn for proofreading. If you have any other questions/comments, find me on twitter at @asanso

tl;dr: Besu Ethereum execution client version 25.2.2 suffered from a consensus issue related to the EIP-196/EIP-197 precompiled contract handling for the elliptic curve alt_bn128 (a.k.a. bn254). The issue was fixed in release 25.3.0. Here is the full CVE report.

N.B.: Part of this post requires some knowledge about elliptic curves (cryptography).

Introduction

The bn254 curve (also known as alt_bn128) is an elliptic curve used in Ethereum for cryptographic operations. It supports operations such as elliptic curve cryptography, making it crucial for various Ethereum features. Prior to EIP-2537 and the recent Pectra release, bn254 was the only pairing curve supported by the Ethereum Virtual Machine (EVM). EIP-196 and EIP-197 define precompiled contracts for efficient computation on this curve. For more details about bn254, you can read here.

A significant security vulnerability in elliptic curve cryptography is the invalid curve attack, first introduced in the paper “Differential fault attacks on elliptic curve cryptosystems”. This attack targets the use of points that do not lie on the correct elliptic curve, leading to potential security issues in cryptographic protocols. For non-prime order curves (like those appearing in pairing-based cryptography and in G2G_2 for bn254), it is especially important that the point is in the correct subgroup. If the point does not belong to the correct subgroup, the cryptographic operation can be manipulated, potentially compromising the security of systems relying on elliptic curve cryptography.

To check if a point P is valid in elliptic curve cryptography, it must be verified that the point lies on the curve and belongs to the correct subgroup. This is especially critical when the point P comes from an untrusted or potentially malicious source, as invalid or specially crafted points can lead to security vulnerabilities. Below is pseudocode demonstrating this process:

# Pseudocode for checking 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 checks

As mentioned above, when working with any point of unknown origin, it is crucial to verify that it belongs to the correct subgroup, in addition to confirming that the point lies on the correct curve. For bn254, this is only necessary for G2G_2, because G1G_1 is of prime order. A straightforward method to test membership in GG is to multiply a point by the subgroup’s prime order nn; if the result is the identity element, then the point is in the subgroup. However, this method can be costly in practice due to the large size of the prime rr, especially for G2G_2. In 2021, Scott proposed a faster method for subgroup membership testing on BLS12 curves using an easily computable endomorphism, making the process 2×, 4×, and 4× quicker for different groups (this technique is the one specified in EIP-2537 for fast subgroup checks, as detailed in this document). Later, Dai et al. generalized Scott's technique to work for a broader range of curves, including BN curves, reducing the number of operations required for subgroup membership checks. In some cases, the process can be nearly free. Koshelev also introduced a method for non-pairing-friendly curves using the Tate pairing, which was eventually further generalized to pairing-friendly curves.

The Real Slim Shady

As you can see from the timeline at the end of this post, we received a report about a bug affecting Pectra EIP-2537 on Besu, submitted via the Pectra Audit Competition. We're only lightly touching on that issue here, in case the original reporter wants to cover it in more detail. This post focuses specifically on the BN254 EIP-196/EIP-197 vulnerability.

The original reporter observed that in Besu, the is_in_subgroup check was performed before the is_on_curve check. Here's an example of what that might look like:

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

Intrigued by the issue above on the BLS curve, we decided to take a look at the Besu code for the BN curve. To my great surprise, we found something like this:

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

Wait, what? Where is the is_on_curve check? Exactly—there isn't one!!!

Now, to potentially bypass the is_valid_point function, all you'd need to do is provide a point that lies within the correct subgroup but isn't actually on the curve.

But wait—is that even possible?

Well, yes—but only for particular, well-chosen curves. Specifically, if two curves are isomorphic, they share the same group structure, which means you could craft a point from the isomorphic curve that passes subgroup checks but doesn't lie on the intended curve.

Sneaky, right?

Did you say isomorpshism?

Feel free to skip this section if you're not interested in the details—we're about to go a bit deeper into the math.

Let Fq\mathbb{F}_q be a finite field with characteristic different from 2 and 3, meaning q=pfq = p^f for some prime p≥5p \geq 5 and integer f≥1f \geq 1. We consider elliptic curves EE over Fq\mathbb{F}_q given by the short Weierstraß equation:

y2=x3+Ax+By^2 = x^3 + A x + B

where AA and BB are constants satisfying 4A3+27B2≠04A^3 + 27B^2 \neq 0.^[This condition ensures the curve is non-singular; if it were violated, the equation would define a singular point lacking a well-defined tangent, making it impossible to perform meaningful self-addition. In such cases, the object is not technically an elliptic curve.]

Curve Isomorphisms

Two elliptic curves are considered isomorphic^[To exploit the vulnerabilities described here, we really want isomorphic curves, not just isogenous curves.] if they can be related by an affine change of variables. Such transformations preserve the group structure and ensure that point addition remains consistent. It can be shown that the only possible transformations between two curves in short Weierstraß form take the shape:

(x,y)↦(e2x,e3y)(x, y) \mapsto (e^2 x, e^3 y)

for some nonzero e∈Fqe \in \mathbb{F}_q. Applying this transformation to the curve equation results in:

y2=x3+Ae4x+Be6y^2 = x^3 + A e^{4} x + B e^{6}

The jj-invariant of a curve is defined as:

j=17284A34A3+27B2j = 1728 \frac{4A^3}{4A^3 + 27B^2}

Every element of Fq\mathbb{F}_q can be a possible jj-invariant.^[Both BLS and BN curves have a j-invariant equal to 0, which is really special.] When two elliptic curves share the same jj-invariant, they are either isomorphic (in the sense described above) or they are twists of each other.^[We omit the discussion about twists here, as they are not relevant to this case.]

Exploitability

At this point, all that's left is to craft a suitable point on a carefully chosen curve, and voilà—le jeu est fait.

You can try the test vector using this link and enjoy the ride.

Conclusion

In this post, we explored the vulnerability in Besu's implementation of elliptic curve checks. This flaw, if exploited, could allow an attacker to craft a point that passes subgroup membership checks but does not lie on the actual curve. The Besu team has since addressed this issue in release 25.3.0. While the issue was isolated to Besu and did not affect other clients, discrepancies like this raise important concerns for multi-client ecosystems like Ethereum. A mismatch in cryptographic checks between clients can result in divergent behavior—where one client accepts a transaction or block that another rejects. This kind of inconsistency can jeopardize consensus and undermine trust in the network’s uniformity, especially when subtle bugs remain unnoticed across implementations. This incident highlights why rigorous testing and robust security practices are absolutely essential—especially in blockchain systems, where even minor cryptographic missteps can ripple out into major systemic vulnerabilities. Initiatives like the Pectra audit competition play a crucial role in proactively surfacing these issues before they reach production. By encouraging diverse eyes to scrutinize the code, such efforts strengthen the overall resilience of the ecosystem.

Timeline

• 15-03-2025 – Bug affecting Pectra EIP-2537 on Besu reported via the Pectra Audit Competition.
• 17-03-2025 – Discovered and reported the EIP-196/EIP-197 issue to the Besu team.
• 17-03-2025 – Marius Van Der Wijden created a test case and statetest to reproduce the issue.
• 17-03-2025 – The Besu team promptly acknowledged and fixed the issue.