CVE-2025-30147 – The curious case of subgroup check on Besu

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 Justin Traglia, Marius Van Der Wijden, Benedict Wagner, and Kevaundray Wedderburn for proofreading. If you have any other questions/comments, find me on twitter at https://twitter.com/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 $G_2$

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 $G_2$

However, this method can be costly in practice due to the large size of the prime $r$, especially for $G_2$

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 $\mathbb{F}_q$

\begin{equation}\tag{1}
y^2 = x^3 + A x + B
\end{equation}

where $A$ and $B$ are constants satisfying $4A^3 + 27B^2 \neq 0$

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:

\begin{equation}\tag{2}
(x, y) \mapsto (e^2 x, e^3 y)
\end{equation}

for some nonzero $e \in \mathbb{F}_q$

\begin{equation}\tag{3}
y^2 = x^3 + A e^{4} x + B e^{6}
\end{equation}

The $j$-invariant of a curve is defined as:
\begin{equation}\tag{4}
j = 1728 \frac{4A^3}{4A^3 + 27B^2}
\end{equation}

Every element of $\mathbb{F}_q$

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.