Vulnerability Disclosure Report: XRPL Manifest Flood

Date Reported: July 30, 2026

Affected Version(s): xrpld up to 3.2.0

In the evening of Thursday, July 30, 2026 (Pacific Time) a flood of manifest messages propagated across the XRP Ledger's peer-to-peer network and overwhelmed the manifest-handling logic in xrpld, causing mass peer disconnects. Many nodes lost a majority of their peers within minutes, including two UNL nodes (Ripple and XRPSCAN).

Developers from the community swiftly responded to the incident, diagnosed the root cause, shipped an emergency mitigation (the in-progress 3.3.0-rc6 build) to several XRP Ledger nodes within a few hours, confirmed the mitigation was effective, and released a standalone public hotfix (3.2.1) to the wider community by the evening of July 31st.

The underlying XRPL ledger never halted or forked, and the remaining UNL validators maintained consensus throughout the flood. No loss of funds, private key compromise, or ledger data-integrity issue occurred. This was an availability/resource-exhaustion event affecting peer connectivity and downstream reporting services (Explorer, s1/s2 full-history endpoints, Clio), not a consensus or security breach.

One or more sources on the network began flooding peers with a very high volume of synthetic “revocation-only” manifests for validator identities with no prior history. Our monitoring system alerted us of unusual behavior occurring on Mainnet.

The protocol was designed to relay all received manifests onward regardless of trust status, because another node might be interested in them. However, any node whose cache became “poisoned” with junk manifests would re-broadcast all of them on every (re)connection, causing the flood to self-amplify: ordinary connection churn (including churn the flood itself was causing) repeatedly re-triggered fresh waves of the same traffic across the network.

Possible causes that triggered the manifest flood to start:

1. A validator could have added multiple nodes with an older version at once.
2. Old nodes with very old manifest caches hanging on to the instances.
3. Intentional or accidental targeting via a modified version of the xrpld software.

Combining our analysis with the one performed by Peersyst, we suspect it was either an intentional act or an experiment gone rogue. During the manifest flood, Peersyst observed tens of thousands of revocation-only manifests being sent whose identities were all new and had not sent any prior active manifests. They also saw more than 100k verified active manifests using unique master/signing keys and sequences, but with the identical synthetic 128-character domain that looked like 63*a + "." + 61*b + ".cc". Moreover, they figured out the amplification mechanism by seeing that many of the relays were replays of flood manifests they recorded during the previous month, blasted at 100-165 per second.

A smaller-scale version of the same underlying manifest-cache issue had already been flagged in response to a community report, and the following fixes were ready for inclusion in version 3.3.0 that was scheduled to be released the week after.

• fix: Bound untrusted manifest cache
• fix: Reduce untrusted manifest cache cap to 100
• fix: Reject oversized validator manifest before decoding
• fix: Cap untrusted manifests per message and drop oversized ones

These changes modified the behavior of the xrpld peer-to-peer protocol, which until then had placed no upper bound on the following three components:

• The size of an individual manifest entry,
• The number of manifest entries carried in a single manifest message, and
• The number of entries a node would retain in its manifest cache, including manifests for validators the node does not track or trust.

As these changes had already been subject to weeks of testing, we pulled them forward into the 3.2.1 hotfix that we released on July 31st. The hotfix effectively bounded the manifest size, per-message manifest count, and cache size. As part of the release we instructed all operators to perform one graceful restart post-upgrade to flush any already-cached untrusted manifests from disk.

Note that after the release we observed that we had tightened the limits on the untrusted manifests too much, which prevented the peer gossip protocol from functioning correctly while the flood was still ongoing, as it was drowning out legitimate untrusted manifests being shared between peers. Although that particular problem would go away by itself once sufficient nodes updated to 3.2.1, we loosened the caps in 3.3.0 that was released the week after.

• fix: Increase manifest protocol message size cap and fix manifests relay

• ​​Implement a robust filtering of incoming traffic and limit/paginate outgoing traffic, across all message types. This includes generalizing backpressure mechanisms (throttling, dynamic fees, clock slowdown, etc.) so the same protections apply not only to manifests but to all network traffic, with limits tailored to each message.
• Expand and improve instrumentation (logging, metrics, and traces) as well as monitoring and alerting. This includes supporting the XRPLF's unified telemetry effort so the earliest signs of trouble among any of the participating validators are detected and can be acted upon.

We quickly pushed out a hotfix in version 3.2.1 to protect the network, especially the UNL validators. Version 3.3.0 is currently the latest version available that expands upon 3.2.1 with additional fixes and functionality. We encourage everyone to upgrade to 3.3.0 at their earliest convenience.

We'd like to thank the following community members for their assistance with resolving the manifest flood:

• Ripple
• XRPL Foundation
• Peersyst
• Flare Network
• Daniel Keller
• XRPKuwait
• Nikolaos Bougalis
• xrpl.to
• FrancisBovineSwift
• Hamsa
• Onledger

• Introducing XRP Ledger version 3.2.1
• Introducing XRP Ledger version 3.3.0

To report security issues, see the xrpld Security Policy.