XRP Ledger fixed 2 critical bugs in xrpld 3.4.1

XRP Ledger fixed 2 critical bugs in xrpld 3.4.1, and one of them could have allowed XRP to be issued without backing. The second threatened network consistency. This matters for XRP holders, validators, and anyone following network security.

The XRPL team published a report on two vulnerabilities in the xrpld software. Both were closed in version 3.4.1, released on September 25. The first issue was found on September 22, 2026, through the bug bounty program. The second was noticed during a recheck of the Sherlock Attackathon results.

Why was this bug so dangerous?

The first vulnerability involved an integer overflow in the payment mechanism. In short, the system could miscalculate hundreds of orders. In that case, an attacker could create XRP out of thin air. For a network with a fixed supply, that is very serious.

The team says the issue may have existed since 2015. That was when the current payment mechanism was introduced. In xrpld 3.4.1, overflow checks were added during amount calculations and balance controls were tightened. This reduces the risk of a similar mistake happening again in the future.

According to the XRPL vulnerability report, the issue was initially rated Major, and after reproduction RippleX raised it to Critical. The researchers who helped with disclosure were named publicly: Cayden Liao and Veria AI. This is a rare case where a technical flaw received such a precise and fast analysis. And that is what saved time.

What happened with batch transactions?

The second bug was different. It involved the Batch mechanism, which allows up to 8 transactions to be combined into one package. The server did not check whether each internal transaction had the required RawTransaction field. Because of this, different versions of xrpld could evaluate the same operation differently.

Here the risk was not issuance, but stability. In the worst-case scenario, this could create discrepancies between servers and stop the confirmation of new ledgers. The team fixed the issue through the fixBatchV1_2 update, which was activated on mainnet on October 9. Before that, BatchV1_1 had not yet been enabled, so the bug was not exploited on Mainnet.

On the day of release, more than 80% of default UNL validators were already running xrpld 3.4.1. That matters for the network. When versions diverge, the risk of confusion rises very quickly.

Network and market reaction

XRPL showed no signs of a widespread failure. The team said it found no evidence of exploitation of the overflow vulnerability on public networks. And the batch transaction issue did not affect the main network because the relevant protocol update had not yet been activated. This is an important point. The bug was found before it had time to turn into a real incident.

For the market, such news usually means not panic, but a trust check. According to the market tracker, as of October 10, 2026 XRP was trading at around $1.40, market capitalization reached $88.55 billion, and about 63 billion XRP were in circulation. This is not a small network, so even one vulnerability here has major resonance.

• The xrpld 3.4.1 update closed 2 separate bugs.

• One of them could have affected XRP issuance.

• The other could have broken consistency between server versions.

• The first issue was found on September 22, 2026.

• The fixBatchV1_2 update was activated on October 9.

• More than 80% of default UNL validators were already on 3.4.1 on release day.

What does this mean for investors?

For XRP holders, the main takeaway is simple. The network closed two technical holes in time. That does not remove all risks, but it shows the team responds quickly. And that matters right now, when trust in infrastructure often moves the price as much as partnership news.

There is also a broader context. In 2025, XRPL had already experienced a shutdown of about 64 minutes at around block height 93,927,174. So any new validity issue immediately draws close attention. Against this backdrop, the rapid move to 3.4.1 and the mass validator migration look like an attempt to prevent a small bug from turning into a network crisis.

One more nuance for Ukrainian users. If XRP is used as a fast transfer asset, network security matters no less than the exchange rate. When the protocol closes such holes, it reduces technical risk for those who hold the coin or transfer it between wallets. Those who want to quickly sell Bitcoin on Monobank also watch such news, because technical network problems often affect decisions in the moment.

Frequently asked questions

Could the vulnerability in XRP Ledger really create new XRP?

Yes, that was exactly the issue in the first bug. According to the team’s description, overflow in the payment mechanism could have allowed XRP to be issued without backing. In xrpld 3.4.1, this logic was closed with additional checks.

Did this bug stop the XRP Ledger network?

No, there was no evidence of exploitation on public networks. The second vulnerability also did not affect Mainnet because the required protocol update had not yet been activated. But the risk to network consistency was real.

What have validators and developers already done?

The team released xrpld 3.4.1, and more than 80% of default UNL validators were already running it on release day. Later, fixBatchV1_2 was activated on ledger 107,540,481, and BatchV1_1 was enabled on ledger 107,540,993. This helped quickly align the network state.

This time, XRP Ledger managed to fix the problem before a major failure. And that is the most important news for everyone who follows XRP not only as a coin, but as a working network.

This material is not financial advice. Cryptocurrency trading involves significant risks. Part of this text was prepared with the help of artificial intelligence based on public sources and reviewed by our editorial team.