The security of a blockchain-based financial infrastructure extends beyond protecting the keys users rely on to authorise transactions: it also depends on the software’s ability to enforce the protocol’s rules correctly. An error in the code used across the network can compromise transaction integrity even when signatures are valid and checks appear to pass normally. This was the issue exposed by the vulnerability patched in XRP Ledger in September 2026, which could have allowed XRP to be created in breach of the rules governing its supply. The flaw was reproduced in a local environment, with no evidence of exploitation on the public network. What makes the case particularly significant is the contribution attributed to artificial intelligence in its discovery: the ability to uncover vulnerabilities that have remained unnoticed for years also requires a reassessment of response times. In this setting, security depends as much on detecting a flaw as on the speed with which it can be verified, corrected and protected against exploitation.
Supply integrity and the independence of controls
XRP Ledger is a public blockchain whose native asset, XRP, has a defining characteristic: its initial supply of 100 billion units cannot be increased through the normal operation of the protocol. Transaction fees also progressively reduce the total quantity of XRP. The vulnerability, reported on 22 September 2026, undermined this principle. It affected the payment engine, which can draw on offers in the network’s integrated exchange. When calculating amounts, the software could exceed the limits of its numerical representation and return a total lower than the actual amount. The same problem affected the control responsible for preventing new issuance, allowing it to accept an incorrect result.
In the researchers’ demonstration, a single transaction could generate approximately 18.45 trillion XRP, more than 184 times the initial supply. This figure illustrates the vulnerability’s potential scale; it does not imply that issuance occurred on the public network or that an economic loss was realised. The presence of the same error in both the payment engine and the supply control exposes a specific weakness in the protocol’s design: two components with different responsibilities can fail simultaneously if they share the same weaknesses. For a financial infrastructure, this makes it essential to examine how its layers of protection interact and how a single error could affect the network’s overall operation.
Artificial intelligence and the reassessment of existing software
The flaw in the payment engine dated back to 2015, while the control against new issuance had been introduced in 2017. Veria Labs, the research team that reported the vulnerability, attributes the discovery of both problems and their combination into a local proof of concept to its artificial intelligence agent. Researchers subsequently reviewed the demonstration. The case shows how these tools can uncover weaknesses arising from interactions between components developed at different times. The issue extends beyond blockchains: software used for decades can also contain vulnerabilities that emerge only under particular conditions or through a combination of flaws.
One example comes from Anthropic, which documented the discovery, using its Mythos Preview model, of vulnerabilities that had existed for 27 years in the OpenBSD operating system and for 16 years in the FFmpeg multimedia library. Such findings show how long weaknesses can remain unnoticed even in widely used software. For operators of critical infrastructure, this reinforces the importance of supplementing routine maintenance with deeper periodic reviews. Artificial intelligence can make a significant contribution to this work, but its effectiveness also depends on researchers’ ability to confirm findings, assess their implications and establish the conditions under which a flaw could be exploited. At the same time, the availability of more powerful tools can increase the pressure on those protecting systems already in production, making timely detection and remediation even more important.
Previous cases and the distinction between discovery and prevention
Artificial intelligence has already contributed to the discovery of significant vulnerabilities in the crypto sector. On 19 February 2026, Pranamya Keshkamat and Apex, the security tool developed by Cantina AI, discovered an error in the signature verification logic of XRP Ledger’s Batch feature, designed to group multiple transactions. The flaw could have allowed transactions to be executed on behalf of other users without access to their private keys. As the feature had not yet been activated on the main network, its vulnerable implementation could be prevented from going live, avoiding exposure for users. Another example is the research programme run by RippleX, the Ripple team dedicated to developing the protocol and tools for the XRP Ledger ecosystem. The initiative combines AI-assisted analysis, testing under adverse conditions and human review, and contributed to fixes included in software version 3.1.3. This approach shows how such tools can support researchers within a process that requires technical verification and specialist oversight.
Comparison with the arithmetic vulnerability reported in September highlights two different operational situations. When a flaw is identified before a feature is activated, it can be corrected before the feature enters use on the public network, limiting users’ exposure. When the vulnerability affects software already in operation, however, remediation must take place while the infrastructure continues to process transactions. Risk management must then reconcile the speed of remediation, the coordination of upgrades and the continuity of consensus between nodes. Even a technically effective fix requires coordinated deployment to limit the risk of divergence in the application of protocol rules. The ability to respond therefore also depends on how interventions are organised and whether the network can be protected without compromising its operation.
Remediation and the network’s exposure window
The vulnerability was reported on 22 September and verified by RippleX engineers; version 3.4.1 of the xrpld software, developed in collaboration with the XRP Ledger Foundation, was announced on 25 September. The fix introduces checks on arithmetic sums and strengthens the control against new issuance. Changes to transaction processing are normally activated through amendments, after maintaining support from more than 80% of trusted validators for two weeks. This procedure allows servers to apply the new rules from the same point in the ledger. In this case, however, protection took effect on each server as soon as it was upgraded.
Waiting would have prolonged exposure to a flaw that publication of the fix could have helped reveal; for the same reason, the source code was initially withheld. During the transition, however, an attempted exploit could have been accepted by servers running the previous version and rejected by upgraded servers, causing ledger divergence or a network halt. Ordinary transactions were unaffected by this difference. The official vulnerability report does not indicate that this scenario occurred and states that more than 80% of validators included in the default trusted validator list had upgraded their software on the day of release. Rapid adoption therefore limited the period during which versions applying different rules coexisted.
Conclusions
The XRP Ledger case shows how artificial intelligence can accelerate the discovery of vulnerabilities that have remained unnoticed for years, changing the security conditions even for infrastructure with a long operating history. The benefits for defensive research are accompanied by the possibility that the same advances will allow attackers to identify and exploit flaws more quickly. Timely action is therefore essential: verifying the report, correcting the software and ensuring that protection reaches the systems in use. In the XRP Ledger case, this process addressed a threat to supply integrity without evidence emerging of exploitation on the public network. As analytical tools evolve, security increasingly depends on the ability to move quickly from discovering a vulnerability to effectively containing the risk it creates.
