# Vulnerability Disclosure Report: XRPL Manifest Flood

**Date Reported:** July 30, 2026

**Affected Version(s):** `xrpld` up to 3.2.0

## Summary of Vulnerability

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.

## Impact

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.

## Technical Details

### Discovery

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.

### Root Cause

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.

### Exploit Path

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.

### Remediation

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](https://github.com/XRPLF/rippled/commit/587505ef186c3dc1937570a5911caab851c467e2)
* [fix: Reduce untrusted manifest cache cap to 100](https://github.com/XRPLF/rippled/commit/32a9cc4038e62ee87c7a2eb5e03f1f028507a8a7)
* [fix: Reject oversized validator manifest before decoding](https://github.com/XRPLF/rippled/commit/0cce5a06d994cb1c45419e2b7016843ba5817748)
* [fix: Cap untrusted manifests per message and drop oversized ones](https://github.com/XRPLF/rippled/commit/4bd1d1ca2f01952b9ef533bc4bd8abc2046bfce8)


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](https://github.com/XRPLF/rippled/commit/54cfdda00b64b73bf3f9a987ed6467d7fd213e14)


## Security Enhancements Roadmap

* ​​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.


## Fixes / Patches Available

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.

## Acknowledgements

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](https://x.com/xrplto?s=21&t=ZJr2wXLH6YHuEqd9S9EZzA)
* [FrancisBovineSwift](https://x.com/swiftbovine?s=21&t=ZJr2wXLH6YHuEqd9S9EZzA)
* [Hamsa](https://x.com/joshuahamsa?s=21&t=ZJr2wXLH6YHuEqd9S9EZzA)
* [Onledger](https://x.com/offledger)


## References

* [Introducing XRP Ledger version 3.2.1](https://xrpl.org/blog/2026/xrpld-3.2.1)
* [Introducing XRP Ledger version 3.3.0](https://xrpl.org/blog/2026/xrpld-3.3.0)


## Contact

To report security issues, see the [`xrpld` Security Policy](https://github.com/XRPLF/rippled/blob/develop/SECURITY.md).

## Incident Response Timeline

| Date | Time (PT) | Event |
|  --- | --- | --- |
| Thu, Jul 30 | 7:45 PM | Earliest sign of anomaly: at least one of Ripple's hubs stops producing normal logs (identified later via log review, not noticed in real time). |
| Thu, Jul 30 | 8:00 PM | The “Clio Ledger Age” alert in Grafana fires on multiple full-history nodes as validated-ledger lag begins. |
| Thu, Jul 30 | 8:05 PM | Multiple “Peer disconnects in the last 5 minutes” alerts fire simultaneously across 23 mainnet hosts (nearly every hub, validator-hub, and Clio P2P instance in several AWS regions). |
| Thu, Jul 30 | 8:51 PM | Incident call convened after XRPSCAN's validator page shows both their own and Ripple’s validator offline. |
| Thu, Jul 30 | 8:55 PM | Observed an abnormal volume of inbound connections and elevated job-queue/peer-age on Ripple's hubs. Started rejecting the highest-volume source IPs rather than restarting. |
| Thu, Jul 30 | 9:05 PM | Hubs fall to single-digit peer counts (normal is several hundred). Ripple’s UNL validator is down to 1 peer because it depends entirely on the hub cluster for peering. |
| Thu, Jul 30 | 9:15 PM | Restarted one of the hubs. Peer count rises briefly but instability continues. Each peer reconnected after the restart triggered a fresh burst of manifest exchange. |
| Thu, Jul 30 | 9:32 PM | AWS regional outage explicitly ruled out via multi-region Grafana checks and Down Detector. |
| Thu, Jul 30 | 9:37 PM | Tried peering through public hubs (XRPL Commons, XRP Kuwait) without success. More IPs were blocked. A total of 7 by now. |
| Thu, Jul 30 | 10:04 PM | Identified the mechanism behind the manifest flood: peers relaying abnormally large volumes of manifest messages, unbounded by any existing size or count limit. Pinpoint four bounding fixes: cap manifest send size, cap manifest receive size, cap manifest cache size, and cap the size of any single manifest entry. |
| Thu, Jul 30 | 10:26 PM | Deployed the in-flight 3.3.0-rc6 build (which already contained most of the manifest-cache fixes) to the hubs. |
| Thu, Jul 30 | 11:30 PM | Decided to start working on a slim, standalone emergency release (3.2.1) with only the manifest fixes, as initial signals on the hubs are positive. Deployed the stopgap version also to Ripple's UNL and non-UNL validators. |
| Fri, Jul 31 | 2:15 AM | Continued stabilization of hubs and validators overnight with 3.3.0-rc6. |
| Fri, Jul 31 | 3:15 AM | Created draft PR with the combined fix in a local repository. |
| Fri, Jul 31 | 4:00 AM | Caught an edge case in the overnight cap logic (specifically, how trusted vs. untrusted manifest entries are counted toward the per-message limit). Aligned on the manifest bounds. |
| Fri, Jul 31 | 5:12 PM | Fix built and staged: deployed first to AMM devnet, then to hub machines one at a time. |
| Fri, Jul 31 | 7:15 PM | Version 3.2.1 tagged and publicly released; release notes published detailing the manifest-handling bounds and the required post-upgrade graceful restart. |