Two findings, different responses

The XRP Ledger published a security disclosure on October 9 describing two vulnerabilities fixed in xrpld version 3.4.1. One concerned validation of transactions inside the Batch feature; the other involved an overflow in the payment engine that could have allowed the creation of XRP. The report says it found no evidence that the overflow issue had been exploited on a public network.

Version 3.4.1 was released September 25. The overflow fix took effect when operators upgraded, while the Batch fix required an amendment that activated on Mainnet October 9. The report states that the affected Batch feature had not been active on Mainnet when the issue was found, and no Mainnet accounts or funds were affected by that finding.

Activation is part of security

A distributed ledger needs its participants to agree on which transactions are valid. Repairing software can therefore involve more than releasing new code. The timing of activation matters when different operators may run different versions, because inconsistent rules can create disagreement about the next ledger state.

Our interpretation is that the disclosure makes this coordination problem unusually visible. A security team has to balance the danger of leaving a vulnerability open against the risks introduced while a network upgrades. Those trade-offs require an understanding of both the technical defect and the practical behavior of validators.

A finding is not evidence of an attack

The distinction between a potential exploit and an observed incident is essential. A report can describe severe hypothetical consequences without establishing that those consequences occurred. In this case, the published findings and remediation timeline should not be presented as a confirmed theft or as proof that unauthorized XRP entered circulation.

The report also describes a stronger re-verification process for findings considered fixed. That principle is straightforward: the release candidate should be tested against the original issue before the finding is closed. A proposed repair and a demonstrated repair are separate milestones.

For network operators, the official report and release guidance are the relevant references for maintenance decisions. For readers following the ecosystem, the disclosure provides evidence of problems identified, fixes shipped and coordination undertaken. It does not establish a price implication for XRP. The broader lesson is that security depends on continued testing and reliable deployment as well as initial code review, particularly when financial rules must remain consistent across many independently operated servers.

Source: https://xrpl.org/es-es/blog/2026/vulnerabilitydisclosurereport-bug-20261009