Vulnerability Disclosure Report: Transaction Set Handling

Copy

• Copy for LLM

  Copy page as Markdown for LLMs
• View as Markdown

  Open this page as Markdown
• Open in ChatGPT

  Get insights from ChatGPT
• Open in Claude

  Get insights from Claude
• Connect to Cursor

  Install MCP server on Cursor
• Connect to VS Code

  Install MCP server on VS Code

This vulnerability disclosure report contains technical details of the XRP Ledger bug reported on June 9, 2025.

Date Reported: June 9, 2025

Affected Version(s): rippled up to 2.6.2

Summary of Vulnerability

Two vulnerabilities that affected XRPL's liveness were discovered by Common Prefix, which could have prevented the network from making forward progress. A UNL validator would need to have been compromised in order to exploit the bugs. Fixes for both vulnerabilities were released as part of version 3.0.0 of rippled.

Impact

If a UNL validator had been compromised before these vulnerabilities were fixed, a modified version of rippled could have been deployed that exploited the bugs. In particular, by manipulating the transaction data in transaction sets, the compromised validator could then cause a crash in all other validators that directly received the modified message. Crashes could then be triggered repeatedly until removal of the compromised validator from the UNL.

Technical Details

Discovery

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

Root Cause

A consensus round between validators is an attempt to agree on a set of transactions so they can be processed and included in the ledger. Each validator proposes a set of unprocessed transactions that they know about, and exchanges messages with other validators to establish a final set of transactions that a supermajority of them can agree on. The two vulnerabilities arose from how the transaction sets disputes were handled in our code.

Both vulnerabilities required one of the ~35 UNL validators to have been compromised, which would open the door to sending a maliciously crafted message that in turn would trigger any receiving node to crash. Even though compromising a UNL validator is challenging since they typically hide behind proxy nodes and only communicate with those nodes, it is not impossible.

Vulnerability 1: comparing transactions

When a validator receives a transaction set from another validator, it compares that transaction set with its own and identifies the transactions that are different ("disputed"). This is where the first vulnerability came into play, as a compromised validator was able to claim that a certain transaction could be found in a node in the SHAMap where it actually was not located. Any validator who received the malicious transaction set would then crash the moment it tried to look up the transaction ID using the invalid node ID.

Vulnerability 2: relaying transactions

When a validator has come across disputed transactions, it will relay them to its peers. The second vulnerability leveraged this functionality, whereby a compromised validator sent a transaction set in which the transaction data was an arbitrary hash. Any validator who received the malicious transaction set would identify this as a disputed transaction and would want to relay it to its peers.

Before relaying a transaction, a validator first checks if it is a pseudo transaction, as those should not be relayed. In this case, when a validator would try to perform this inspection, the invalid data in the transaction set would cause it to crash.

Steps to reproduce

Vulnerability 1: comparing transactions

1. A compromised validator constructs a TxSet where the TxId is not in the correct node.
2. The validator sends an accompanying proposal to its peers.
3. Peer validators receive the position, acquire the TxSet, and attempt to create disputes. This results in a crash when the node ID is used to look up the transaction ID.

Vulnerability 2: relaying transactions

1. A compromised validator constructs a TxSet containing a SHAMapItem with data that cannot be read by the STTx constructor.
2. The validator sends an accompanying proposal to its peers.
3. Peer validators receive the position, acquire the TxSet, create disputes and attempt to relay them. This results in a crash when the pseudo transaction check is performed.

Remediation

• To protect against the first vulnerability we added an extra check to confirm that a transaction can really be found in the node where the proposal said it would be.
• To protect against the second vulnerability we added a try-catch to handle the exception that the code will throw when a malicious transaction is inspected.
• To replicate the findings of Common Prefix, we deployed a modified version of rippled in our testing platform to simulate a compromised UNL validator. Without the first fix, the first attack would indeed crash all nodes that received a malicious message sent by the compromised validator. The same thing happened without the second fix when the second attack was launched. After applying both fixes, nodes that received the manipulated messages would no longer crash.

Security enhancements roadmap

We continue to strengthen XRPL’s security posture through multiple initiatives:

• Expanded security audits to preemptively find issues in unreleased code.
• AI-assisted code reviews to identify security issues.
• Hackathons and increased bug bounty incentives.

Fixes / Patches Available

The fixes were released as part of rippled 3.0.0.

Acknowledgements

We extend our deepest gratitude to Common Prefix for responsibly disclosing both vulnerabilities and for giving us time and assistance to fix them.

Contact

For more information or to report further issues, please see the Bug Bounty Program page.

Incident Response Timeline