Ripple Discloses 2025 XRP Ledger Vulnerabilities After Fixes Deployed in rippled 3.0.0

Ripple published a vulnerability disclosure report on March 23, 2026, detailing two bugs in the XRP Ledger (XRPL) discovered in June 2025 that could have prevented network consensus if a unique node list (UNL) validator had been compromised.

The vulnerabilities, reported by blockchain security firm Common Prefix, were fixed in rippled version 3.0.0 released on December 9, 2025, with fixes tested and validated in October 2025. The disclosure follows responsible disclosure protocols and outlines the technical root causes, impact scenarios, and remediation measures implemented to protect network liveness.

Vulnerability Overview and Impact

Discovery and Reporting

Nikolaos Kamarinakis from Common Prefix reported the vulnerabilities via a responsible disclosure submission on June 9, 2025. Ripple engineering teams validated the report with an independent proof-of-concept that reproduced both bugs in a separate test network.

Affected Versions

The vulnerabilities affected rippled versions up to 2.6.2, the software client that powers the XRP Ledger. Both fixes were incorporated into rippled 3.0.0.

Potential Impact

The vulnerabilities required a UNL validator—one of approximately 35 trusted nodes that participate in consensus—to be compromised. While compromising a UNL validator is challenging because these nodes typically hide behind proxy nodes and communicate only with those nodes, the researchers noted it was not impossible.

If exploited, a compromised validator could manipulate transaction data in transaction sets, causing all other validators that directly received the modified message to crash. Such crashes could be triggered repeatedly until the compromised validator was removed from the UNL, potentially halting network consensus.

Technical Details

Vulnerability 1: Comparing Transactions

The first vulnerability arose from how validators compare transaction sets during consensus. When a validator receives a transaction set from another validator, it compares that set with its own and identifies disputed transactions. A compromised validator could claim that a transaction existed in a node within the SHAMap where it was not actually located. Any validator receiving the malicious transaction set would crash when attempting to look up the transaction ID using the invalid node ID.

Vulnerability 2: Relaying Transactions

The second vulnerability leveraged the relay mechanism for disputed transactions. A compromised validator could send a transaction set in which the transaction data was an arbitrary hash. When receiving validators identified this as a disputed transaction and attempted to relay it, they would perform a check to determine if it was a pseudo transaction. The invalid data in the transaction set would cause the validator to crash during this inspection.

Remediation and Fixes

Fix Implementation

To address the first vulnerability, developers added an extra check to confirm that a transaction can be found in the node where the proposal indicated it would be located. For the second vulnerability, a try-catch handler was added to manage exceptions thrown when malicious transactions are inspected.

Testing and Validation

Ripple deployed a modified version of rippled in its testing platform to simulate a compromised UNL validator. Without the fixes, both attacks would crash all nodes receiving malicious messages. After applying both fixes, nodes receiving manipulated messages no longer crashed.

Timeline

• June 9, 2025: Initial discovery and report submission

• July 10, 2025: Test bed deployed

• August 6, 2025: First vulnerability reproduced

• August 11, 2025: Second vulnerability reproduced

• August 19, 2025: Fixes created in private repository

• October 10, 2025: Common Prefix tested the fixes

• October 16, 2025: Common Prefix approved the fixes

• December 9, 2025: Fixes released in rippled 3.0.0

• March 23, 2026: Public vulnerability disclosure report published

Security Enhancements

Ripple outlined ongoing security initiatives to strengthen XRPL’s security posture, including expanded security audits for unreleased code, AI-assisted code reviews, hackathons, and increased bug bounty incentives.

Frequently Asked Questions

What vulnerabilities were discovered in the XRP Ledger?

Two vulnerabilities were discovered in rippled versions up to 2.6.2 that could have prevented network consensus if a UNL validator was compromised. The first involved invalid transaction ID lookups during dispute resolution, and the second involved malformed transaction data causing crashes during relay checks.

Were these vulnerabilities exploited?

No. The vulnerabilities were discovered through responsible disclosure by Common Prefix, and fixes were deployed in rippled 3.0.0 on December 9, 2025, before any known exploitation occurred.

What is a UNL validator and why is it significant?

A UNL (unique node list) validator is a trusted node that participates in XRP Ledger consensus. Approximately 35 validators make up the default UNL. Compromising a UNL validator is challenging because they typically communicate through proxy nodes, but the researchers noted it was not impossible. The vulnerabilities would have required such a compromise to be exploited.