CVE-2025-30147-The curious case of verification of the subgroup on Besu

Thanks to Marius Van der Wijden for creating the test case and Statest, and for helping the Besu team confirm the problem. In addition, congratulations to the Besu team, the EF security team and Kevaundray Wedderburn. In addition, thanks to Justin Traglia, Marius van der Wijden, Benedikt Wagner and Kevaundray Wedderburn for proofreading. If you have any other questions / comments, find me on Twitter in @ASANSO

tl; DR:: Besu Ethereum Execution Customer Version 25.2.2 suffered from a consensus problem linked to EIP-196/ /EIP-197 Management of precompiled contracts for the elliptical curve alt_bn128 (AKA BN254). The problem was resolved to the release 25.3.0.
Here is the full CVE report.

Nb: Part of this article requires knowledge on elliptical curves (cryptography).

Introduction

THE BN254 curve (also known as alt_bn128) is an elliptical curve used in Ethereum for cryptographic operations. It supports operations such as elliptical cryptography of the curve, which makes it crucial for various Ethereum features. Before EIP-2537 and the recent version of Pectra, BN254 was the only matching curve supported by the Ethereum virtual machine (EVM). EIP-196 And EIP-197 Define the precompiled contracts for an effective calculation on this curve. For more details on BN254you can read here.

Significant security vulnerability in elliptical curve cryptography is the Und valid curve attackfirst introduced into the newspaper “Differential defect attacks against elliptical curve cryptosystems”. This attack targets the use of points that are not on the right elliptical curve, leading to potential security problems in cryptographic protocols. For unpaid (like those appearing in cryptography based on twins and in $G_2$

To check if a point P is valid in the cryptography of the elliptical curve, it must be verified that the point is on the curve and belongs to the correct subgroup. This is particularly critical when the point P comes from an unreliable or potentially malicious source, because the invalid or specially designed points can lead to safety vulnerabilities. You will find below 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’s membership verification

As mentioned above, when you work with any point of unknown origin, it is crucial to check that it belongs to the correct subgroup, in addition to confirming that the point is on the correct curve. For BN254It is only necessary for $G_2$

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

The real shaded slim

As you can see in the chronology at the end of this post, we received a report on a bug affecting Pectra EIP-2537 on Besu, subject via the Pectra audit competition. We only approach this question here, in case the original journalist wants to cover him in more detail. This message focuses specifically on the BN254 EIP-196/ /EIP-197 vulnerability.

The original journalist observed that in Besu, the is_in_subgroup The check was made before is_on_curve check. Here is an example of what it 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 above problem on the BLS curve, we decided to take a look at the Besu code for the BN curve. To my surprise, we found something like that::

# 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 is none !!!

Now, to potentially bypass the is_valid_point function, all you would need to do is provide a point This lies in the correct subgroup but is not really on the curve.

But wait – is it even possible?

Well, yes, but only for special and well -chosen curves. More specifically, if two curves are isomorphicThey share the same group structure, which means that you can develop a point of the isomorphic curve which passes from subgroup checks but is not on the planned curve.

Sneaky, right?

Have you said isomorpshism?

Do not hesitate to ignore this section if you are not interested in details – we will go a little further in mathematics.

To leave $\ mathbb {f} _Q$

Or $A$ And $B$ Are the constants satisfactory $4a ^ 3 + 27b ^ 2 \ Neq 0$

Curve isomorphisms

Two elliptical curves are considered isomorphic^ (To exploit the vulnerabilities described here, we really want isomorphic curves, not just isogene Curves.) If they can be linked by a change refinement of variables. These transformations preserve the structure of the group and guarantee that the addition of points remains coherent. We can show that the only possible transformations between two curves in the form of Weaierstraß Courts take the form:

for a little zero $e \ in \ mathbb {f} _Q$

THE $J$-Invariant of a curve is defined as:

Each element of $\ mathbb {f} _Q$

Exploitability

At this point, it only remains to develop an appropriate point on a carefully chosen curve, and that’s it –The game is done.

You can try the test vector using This link And enjoy the ride.

Conclusion

In this article, we explored the vulnerability of the implementation of Besu elliptical curve checks. This defect, if it is used, could allow an attacker to develop a point that passes from membership checks to the subgroup but is not on the real curve. The Besu team has since addressed this problem in version 25.3.0. Although the problem was isolated in Besu and did not affect other customers, differences like this raise important concerns for multi-other ecosystems like Ethereum. A discrepancy in cryptographic controls between customers can lead to divergent behavior – where a customer accepts a transaction or block another reject. This type of inconsistency can compromise consensus and undermine confidence in network uniformity, in particular when subtle bugs remain unnoticed between implementations. This incident highlights why rigorous tests and robust security practices are absolutely essential, especially in blockchain systems, where even minor cryptographic schemes can collapse in major systemic vulnerabilities. Initiatives like the Pectra audit competition play a crucial role in the overhaul of these problems before achieving production. By encouraging various eyes to examine the code, these efforts strengthen the overall resilience of the ecosystem.

Chronology

• 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 number to the Besu team.
• 17-03-2025-Marius van der Wijden created a test case and a state to reproduce the problem.
• 17-03-2025-The Besu team quickly recognized and fixed the problem.