{"id":17507,"date":"2026-02-21T18:28:37","date_gmt":"2026-02-21T18:28:37","guid":{"rendered":"https:\/\/cryptoted.net\/index.php\/2026\/02\/21\/cve-2025-30147-the-curious-case-of-subgroup-check-on-besu\/"},"modified":"2026-02-21T18:28:37","modified_gmt":"2026-02-21T18:28:37","slug":"cve-2025-30147-the-curious-case-of-subgroup-check-on-besu","status":"publish","type":"post","link":"https:\/\/cryptoted.net\/index.php\/2026\/02\/21\/cve-2025-30147-the-curious-case-of-subgroup-check-on-besu\/","title":{"rendered":"CVE-2025-30147 – The curious case of subgroup check on Besu"},"content":{"rendered":"


\n<\/p>\n

\n

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<\/a><\/em><\/p>\n

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

N.B.<\/strong>: Part of this post requires some knowledge about elliptic curves (cryptography).<\/p>\n

<\/g><\/svg><\/a>Introduction<\/h2>\n

The bn254<\/span> curve (also known as alt_bn128<\/span>) 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<\/a> and the recent Pectra release, bn254<\/span> was the only pairing curve supported by the Ethereum Virtual Machine (EVM). EIP-196<\/a> and EIP-197<\/a> define precompiled contracts for efficient computation on this curve. For more details about bn254<\/span>, you can read here<\/a>.<\/p>\n

A significant security vulnerability in elliptic curve cryptography is the invalid curve attack<\/strong>, first introduced in the paper \u201cDifferential fault attacks on elliptic curve cryptosystems\u201d<\/a>. 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<\/mi>2<\/mn><\/msub><\/mrow>G_2<\/annotation><\/semantics><\/math><\/span>G<\/span>2<\/span><\/span><\/span><\/span>\u200b<\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span> for bn254<\/span>), it is especially important that the point is in the correct subgroup<\/strong>. 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.<\/p>\n

To check if a point P<\/span> 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<\/span> 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:<\/p>\n

\n
# Pseudocode for checking if point P is valid<\/span>\n<\/span>def<\/span> <\/span>is_valid_point<\/span>(<\/span>P<\/span>)<\/span>:<\/span>\n<\/span>    <\/span>if<\/span> <\/span>not<\/span> is_on_curve<\/span>(<\/span>P<\/span>)<\/span>:<\/span>    \n<\/span>        <\/span>return<\/span> <\/span>False<\/span>\n<\/span>    <\/span>if<\/span> <\/span>not<\/span> is_in_subgroup<\/span>(<\/span>P<\/span>)<\/span>:<\/span>\n<\/span>        <\/span>return<\/span> <\/span>False<\/span>\n<\/span>    <\/span>return<\/span> <\/span>True<\/span>\n<\/span><\/code><\/pre>\n<\/div>\n
<\/g><\/svg><\/a>Subgroup membership checks<\/h3>\n
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<\/span>, this is only necessary for G<\/mi>2<\/mn><\/msub><\/mrow>G_2<\/annotation><\/semantics><\/math><\/span>G<\/span>2<\/span><\/span><\/span><\/span>\u200b<\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span>, because G<\/mi>1<\/mn><\/msub><\/mrow>G_1<\/annotation><\/semantics><\/math><\/span>G<\/span>1<\/span><\/span><\/span><\/span>\u200b<\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span> is of prime order. A straightforward method to test membership in G<\/mi><\/mrow>G<\/annotation><\/semantics><\/math><\/span>G<\/span><\/span><\/span><\/span><\/span> is to multiply a point by the subgroup\u2019s prime order n<\/mi><\/mrow>n<\/annotation><\/semantics><\/math><\/span>n<\/span><\/span><\/span><\/span><\/span>; if the result is the identity element, then the point is in the subgroup.
\nHowever, this method can be costly in practice due to the large size of the prime r<\/mi><\/mrow>r<\/annotation><\/semantics><\/math><\/span>r<\/span><\/span><\/span><\/span><\/span>, especially for G<\/mi>2<\/mn><\/msub><\/mrow>G_2<\/annotation><\/semantics><\/math><\/span>G<\/span>2<\/span><\/span><\/span><\/span>\u200b<\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span>. In 2021, Scott proposed<\/a> a faster method for subgroup membership testing on BLS12 curves using an easily computable endomorphism<\/em>, making the process 2\u00d7, 4\u00d7, and 4\u00d7 quicker for different groups (this technique is the one specified in EIP-2537<\/a> for fast subgroup checks, as detailed in this document<\/a><\/strong>).
\nLater, Dai et al. generalized Scott’s technique<\/a> 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<\/a>, which was eventually further generalized to pairing-friendly curves.<\/a><\/p>\n
<\/g><\/svg><\/a>The Real Slim Shady<\/h2>\n
As you can see from the timeline at the end of this post, we received a report about a bug affecting Pectra EIP-2537<\/a> on Besu, submitted via the Pectra Audit Competition<\/a>. 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<\/a>\/EIP-197<\/a> vulnerability<\/strong>.<\/p>\n
The original reporter observed that in Besu, the is_in_subgroup<\/span> check was performed before the is_on_curve<\/span> check. Here’s an example of what that might look like:<\/p>\n
\n
# Pseudocode for checking if point P is valid<\/span>\n<\/span>def<\/span> <\/span>is_valid_point<\/span>(<\/span>P<\/span>)<\/span>:<\/span>\n<\/span>    <\/span>if<\/span> <\/span>not<\/span> is_in_subgroup<\/span>(<\/span>P<\/span>)<\/span>:<\/span>    \n<\/span>        <\/span>if<\/span> <\/span>not<\/span> is_on_curve<\/span>(<\/span>P<\/span>)<\/span>:<\/span>\n<\/span>            <\/span>return<\/span> <\/span>False<\/span>  \n<\/span>        <\/span>return<\/span> <\/span>False<\/span>\n<\/span>    <\/span>return<\/span> <\/span>True<\/span>\n<\/span><\/code><\/pre>\n<\/div>\n
\n
# Pseudocode for checking if point P is valid<\/span>\n<\/span>def<\/span> <\/span>is_valid_point<\/span>(<\/span>P<\/span>)<\/span>:<\/span>\n<\/span>    <\/span>if<\/span> <\/span>not<\/span> is_in_subgroup<\/span>(<\/span>P<\/span>)<\/span>:<\/span>    \n<\/span>        <\/span>return<\/span> <\/span>False<\/span>\n<\/span>    <\/span>return<\/span> <\/span>True<\/span>\n<\/span><\/code><\/pre>\n<\/div>\n
Wait, what? Where is the is_on_curve<\/span> check? Exactly\u2014there isn’t one!!!<\/strong><\/p>\n
Now, to potentially bypass the is_valid_point<\/span> function, all you’d need to do is provide a point that lies within the correct subgroup but isn’t actually on the curve<\/strong>.<\/p>\n
But wait\u2014is that even possible?<\/strong><\/p>\n
Well, yes\u2014but only for particular, well-chosen curves. Specifically, if two curves are isomorphic<\/em>, 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.<\/p>\n
Sneaky, right?<\/p>\n
\"\"<\/p>\n
<\/g><\/svg><\/a>Did you say isomorpshism?<\/h3>\n
Feel free to skip this section if you’re not interested in the details\u2014we’re about to go a bit deeper into the math.<\/em><\/p>\n
Let F<\/mi>q<\/mi><\/msub><\/mrow>\\mathbb{F}_q<\/annotation><\/semantics><\/math><\/span>F<\/span>q<\/span><\/span><\/span><\/span>\u200b<\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span> be a finite field with characteristic different from 2 and 3, meaning q<\/mi>=<\/mo>p<\/mi>f<\/mi><\/msup><\/mrow>q = p^f<\/annotation><\/semantics><\/math><\/span>q<\/span>=<\/span><\/span>p<\/span>f<\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span> for some prime p<\/mi>\u2265<\/mo>5<\/mn><\/mrow>p \\geq 5<\/annotation><\/semantics><\/math><\/span>p<\/span>\u2265<\/span><\/span>5<\/span><\/span><\/span><\/span><\/span> and integer f<\/mi>\u2265<\/mo>1<\/mn><\/mrow>f \\geq 1<\/annotation><\/semantics><\/math><\/span>f<\/span>\u2265<\/span><\/span>1<\/span><\/span><\/span><\/span><\/span>. We consider elliptic curves E<\/mi><\/mrow>E<\/annotation><\/semantics><\/math><\/span>E<\/span><\/span><\/span><\/span><\/span> over F<\/mi>q<\/mi><\/msub><\/mrow>\\mathbb{F}_q<\/annotation><\/semantics><\/math><\/span>F<\/span>q<\/span><\/span><\/span><\/span>\u200b<\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span> given by the short Weierstra\u00df equation:<\/p>\n
y<\/mi>2<\/mn><\/msup>=<\/mo>x<\/mi>3<\/mn><\/msup>+<\/mo>A<\/mi>x<\/mi>+<\/mo>B<\/mi><\/mrow>y^2 = x^3 + A x + B   <\/annotation><\/semantics><\/math><\/span>y<\/span>2<\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span>=<\/span><\/span>x<\/span>3<\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span>+<\/span><\/span>A<\/span>x<\/span>+<\/span><\/span>B<\/span><\/span><\/span><\/span><\/span><\/div>\n
where A<\/mi><\/mrow>A<\/annotation><\/semantics><\/math><\/span>A<\/span><\/span><\/span><\/span><\/span> and B<\/mi><\/mrow>B<\/annotation><\/semantics><\/math><\/span>B<\/span><\/span><\/span><\/span><\/span> are constants satisfying 4<\/mn>A<\/mi>3<\/mn><\/msup>+<\/mo>27<\/mn>B<\/mi>2<\/mn><\/msup>\u2260<\/mo>0<\/mn><\/mrow>4A^3 + 27B^2 \\neq 0<\/annotation><\/semantics><\/math><\/span>4<\/span>A<\/span>3<\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span>+<\/span><\/span>27<\/span>B<\/span>2<\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span>\ue020<\/span><\/span><\/span><\/span><\/span><\/span><\/span>=<\/span><\/span><\/span>0<\/span><\/span><\/span><\/span><\/span>.^[This condition ensures the curve is non-singular<\/strong>; 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.]<\/p>\n
<\/g><\/svg><\/a>Curve Isomorphisms<\/h4>\n
Two elliptic curves are considered isomorphic<\/strong>^[To exploit the vulnerabilities described here, we really want isomorphic<\/strong> curves, not just isogenous<\/strong> 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\u00df form take the shape:<\/p>\n
(<\/mo>x<\/mi>,<\/mo>y<\/mi>)<\/mo>\u21a6<\/mo>(<\/mo>e<\/mi>2<\/mn><\/msup>x<\/mi>,<\/mo>e<\/mi>3<\/mn><\/msup>y<\/mi>)<\/mo><\/mrow>(x, y) \\mapsto (e^2 x, e^3 y)<\/annotation><\/semantics><\/math><\/span>(<\/span>x<\/span>,<\/span>y<\/span>)<\/span>\u21a6<\/span><\/span>(<\/span>e<\/span>2<\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span>x<\/span>,<\/span>e<\/span>3<\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span>y<\/span>)<\/span><\/span><\/span><\/span><\/span><\/div>\n
for some nonzero e<\/mi>\u2208<\/mo>F<\/mi>q<\/mi><\/msub><\/mrow>e \\in \\mathbb{F}_q<\/annotation><\/semantics><\/math><\/span>e<\/span>\u2208<\/span><\/span>F<\/span>q<\/span><\/span><\/span><\/span>\u200b<\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span>. Applying this transformation to the curve equation results in:<\/p>\n
y<\/mi>2<\/mn><\/msup>=<\/mo>x<\/mi>3<\/mn><\/msup>+<\/mo>A<\/mi>e<\/mi>4<\/mn><\/msup>x<\/mi>+<\/mo>B<\/mi>e<\/mi>6<\/mn><\/msup><\/mrow>y^2 = x^3 + A e^{4} x + B e^{6}<\/annotation><\/semantics><\/math><\/span>y<\/span>2<\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span>=<\/span><\/span>x<\/span>3<\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span>+<\/span><\/span>A<\/span>e<\/span>4<\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span>x<\/span>+<\/span><\/span>B<\/span>e<\/span>6<\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/div>\n
The j<\/mi><\/mrow>j<\/annotation><\/semantics><\/math><\/span>j<\/span><\/span><\/span><\/span><\/span>-invariant<\/strong> of a curve is defined as:<\/p>\n
j<\/mi>=<\/mo>1728<\/mn>4<\/mn>A<\/mi>3<\/mn><\/msup><\/mrow>4<\/mn>A<\/mi>3<\/mn><\/msup>+<\/mo>27<\/mn>B<\/mi>2<\/mn><\/msup><\/mrow><\/mfrac><\/mrow>j = 1728 \\frac{4A^3}{4A^3 + 27B^2}<\/annotation><\/semantics><\/math><\/span>j<\/span>=<\/span><\/span>1728<\/span>4<\/span>A<\/span>3<\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span>+<\/span>27<\/span>B<\/span>2<\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span>4<\/span>A<\/span>3<\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span>\u200b<\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/div>\n
Every element of F<\/mi>q<\/mi><\/msub><\/mrow>\\mathbb{F}_q<\/annotation><\/semantics><\/math><\/span>F<\/span>q<\/span><\/span><\/span><\/span>\u200b<\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span><\/span> can be a possible j<\/mi><\/mrow>j<\/annotation><\/semantics><\/math><\/span>j<\/span><\/span><\/span><\/span><\/span>-invariant.^[Both BLS and BN curves have a j-invariant equal to 0, which is really special<\/strong>.] When two elliptic curves share the same j<\/mi><\/mrow>j<\/annotation><\/semantics><\/math><\/span>j<\/span><\/span><\/span><\/span><\/span>-invariant, they are either isomorphic<\/strong> (in the sense described above) or they are twists<\/strong> of each other.^[We omit the discussion about twists here, as they are not relevant to this case.]<\/p>\n
<\/g><\/svg><\/a>Exploitability<\/h2>\n
At this point, all that’s left is to craft a suitable point on a carefully chosen curve, and voil\u00e0\u2014le jeu est fait<\/em>.<\/p>\n
You can try the test vector using this link<\/a> and enjoy the ride.<\/p>\n
<\/g><\/svg><\/a>Conclusion<\/h2>\n
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\u2014where one client accepts a transaction or block that another rejects. This kind of inconsistency can jeopardize consensus and undermine trust in the network\u2019s uniformity, especially when subtle bugs remain unnoticed across implementations. This incident highlights why rigorous testing and robust security practices are absolutely essential\u2014especially 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.<\/p>\n
<\/g><\/svg><\/a>Timeline<\/h2>\n
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<\/strong><\/a>:<\/p>\n