Ripple Director of Engineering Vijay Khanna urged XRP Ledger node operators on Aug. 2 to install xrpld version 3.2.1 after developers observed a validator manifest flood on July 31.
Summary
- July 31 manifest flooding prompted xrpld 3.2.1 while XRP Ledger continued closing ledgers normally throughout.
- Four safeguards now cap manifest size, message batches, outbound sharing and unknown-key cache growth network-wide.
- Operators should upgrade, verify xrpld is running, then restart again to clear persisted manifests safely.
The hotfix limits how nodes process, store and share data received from unknown validator identities.
The XRP Ledger continued closing ledgers normally during the event, according to XRP Ledger Operations. The available evidence therefore points to pressure on node resources and peer-to-peer communications rather than a confirmed loss of funds, altered transactions or failure of ledger consensus. Developers have not published a CVE identifier or financial-loss estimate connected to the incident.
XRPL 3.2.1 limits the manifest flood route
Validator manifests are cryptographically signed records that connect a validator’s stable master identity to the temporary key it uses for daily validation messages. When operators rotate those temporary keys, they publish a new manifest signed by the master key so other nodes can verify the change.
Before the hotfix, nodes could accept, cache and rebroadcast validly structured manifests associated with validator keys they did not recognize. An attacker could exploit that behavior by producing many unknown identities and forcing peers to spend memory, storage, bandwidth and processing capacity handling the data. The public code record describes the flaw as a problem with manifest propagation.
The official xrpld 3.2.1 release is dated July 31 and was published as the latest signed release early on Aug. 1. It contains six commits across 13 changed files, including four commits that directly restrict untrusted manifest handling.
Four safeguards reduce resource-exhaustion risk
The first safeguard rejects an oversized validator manifest before the node fully decodes it. That reduces the processing work an attacker can trigger by sending individual objects larger than the software expects.
The second limits the number of untrusted manifests carried in one network message. The cap applies when nodes receive the data and when they prepare manifest messages for peers. Oversized batches are dropped without automatically disconnecting an unpatched peer, which helps upgraded and older nodes remain connected during the rollout.
A third change limits the number of unknown validator identities held in a node’s manifest cache. The final code sets the maximum at 100. Once that capacity is reached, the software rejects manifests tied to new unlisted keys while continuing to process trusted or previously recognized validators.
The patch also changes how untrusted manifest information is retained and propagated. Trusted validator data remains available because the restrictions target unlisted peer gossip rather than manifests from configured or approved validators. This distinction allows normal validator key rotation to continue while blocking unchecked cache growth.
Node operators must complete a second restart
Khanna advised validators and other infrastructure operators to upgrade to version 3.2.1 “as soon as possible.” His instructions call for a normal software update, followed by a wait of one to two minutes and a check that xrpld is running. Operators should then restart the service again.
The second restart is important for nodes that may have retained unknown manifests before installing the fix. Updating changes future handling, while restarting the corrected server helps ensure old in-memory or previously retained data does not continue affecting operations.
Operators may also need to confirm that their systems trust Ripple’s current package-signing key. The release notes state that Ripple rotated the GPG key used to sign xrpld packages on Feb. 18. Existing installations that have not trusted the replacement key may not receive automatic upgrades successfully.
The update applies to infrastructure providers rather than ordinary XRP holders. Users do not need to move XRP, change wallet keys or create new accounts because of the manifest issue. Exchanges, custodians, wallet back ends, data providers and businesses that run their own XRPL servers should instead confirm their node versions and restart status.
The post-mortem will determine the incident’s scope
XRP Ledger Operations said a technical “post-mortem will follow soon.” As of Aug. 2, the project had not published that report, so the identity of the sender, the volume of manifests transmitted and the exact resource use across affected nodes remain undisclosed.
The report should also clarify when developers first detected the activity, whether any nodes became unavailable and how quickly operators adopted version 3.2.1. Although ledgers continued closing, slow patch adoption could leave individual servers exposed to renewed flooding even when the shared ledger remains operational.
The hotfix arrives shortly after XRPL’s larger version 3.2.0 rollout. That release, issued on June 15, renamed the reference server from rippled to xrpld and introduced infrastructure changes that required operators to update software and service configurations.
As previously reported, version 3.2.0 initially spread faster among validators than across the broader node network. The manifest flood adds a new reason for remaining operators to move beyond that release and install the hotfix.
Meanwhile, in related coverage, David Schwartz moved his XRPL infrastructure to version 3.2.0 as developers prepared the network for the new server naming and protocol features. Earlier, as crypto.news reported, node operators also faced a version 3.1.3 deadline tied to an amendment activation.
The next verified updates will be the promised post-mortem and fresh software-adoption data. Until then, the confirmed response remains limited to the 3.2.1 release, its four manifest controls and the request for operators to complete the upgrade and restart process.
Other Articles
No Comment! Be the first one.