Headline: XRPL urges urgent node upgrade after “manifest flood” strains network resources Ripple’s Director of Engineering Vijay Khanna on Aug. 2 urged XRP Ledger node operators to install xrpld v3.2.1 immediately after developers detected a validator “manifest flood” on July 31. The quick hotfix limits how nodes process, store and share manifest data from unknown validator identities — preventing attackers from exhausting node memory, storage, bandwidth and CPU — and preserves normal ledger operation while operators roll out the patch. What happened - On July 31 developers observed a surge of validator manifests coming from unknown identities. Although the ledger continued closing normally, the event put pressure on node resources and peer-to-peer communications. - There is no public evidence of stolen funds, altered transactions or consensus failure. Developers have not issued a CVE nor published a financial-loss estimate tied to the incident. - XRPL Operations said a technical post-mortem will follow; as of Aug. 2 the originator of the flood, the total volume, and exact resource impact remain undisclosed. Why validator manifests matter - Validator manifests are cryptographically signed records that bind a validator’s stable master identity to the temporary keys used for day-to-day validation messages. When operators rotate temporary keys, they publish a new manifest signed by the master key so peers can verify the change. - Before the hotfix, xrpld could accept, cache and rebroadcast properly structured manifests for validator keys it did not recognize. An attacker could exploit that behavior by creating many unknown identities and forcing peers to waste memory, storage, bandwidth and processing power handling the data. The code repository describes the problem as manifest-propagation abuse. What’s in xrpld 3.2.1 - The official xrpld 3.2.1 release (dated July 31; signed and published early Aug. 1) contains six commits across 13 files. Four commits directly limit handling of untrusted manifests. Key protections: - Early rejection of oversized manifests before nodes fully decode them, reducing CPU work per malicious object. - Caps on the number of untrusted manifests allowed in a single network message—applied both on receive and when preparing messages for peers. Oversized batches are dropped without disconnecting unpatched peers, easing rollout compatibility. - A per-node limit on unknown validator identities cached in memory, capped at 100. Once full, new unlisted manifests are rejected while trusted and remembered validators continue to be processed. - Changes to how untrusted manifest info is retained and gossiped, targeting unlisted peer gossip rather than manifests from configured/trusted validators. This preserves legitimate validator key rotation while blocking unchecked cache growth. Operator guidance and rollout notes - Khanna advised validators and infrastructure operators to upgrade to v3.2.1 “as soon as possible.” The recommended process: perform the normal software update, wait one to two minutes to confirm xrpld is running, then restart the service again. The second restart helps purge any unknown manifests retained in memory before the fix. - Operators should also confirm their systems trust Ripple’s current GPG package-signing key. Ripple rotated that key on Feb. 18; nodes that haven’t trusted the new key may not receive automatic upgrades. - This update is for infrastructure operators (exchanges, custodians, wallet back ends, data providers and businesses running XRPL servers). Ordinary XRP holders do not need to move funds, rotate keys, or take any action. Context and next steps - The hotfix follows the broader xrpld v3.2.0 rollout (June 15), which renamed the reference server from rippled to xrpld and required operators to update configurations. v3.2.0 adoption was faster among validators than the wider node network; the manifest flood gives remaining operators another strong reason to move to 3.2.1. - XRPL Operations has promised a technical post-mortem that should detail when the activity was first detected, whether any nodes became unavailable, the volume of manifests, and how quickly operators adopted the patch. Until that report is published, confirmed details remain limited to the 3.2.1 fixes and the request for operators to upgrade and restart. Bottom line If you run XRPL infrastructure, treat this as urgent: upgrade to xrpld 3.2.1 and follow the two-step restart recommendation to clear any retained untrusted manifests. For the wider XRPL community, the incident appears to have been a resource-exhaustion attempt rather than a protocol compromise — but the forthcoming post-mortem will be important to confirm the full scope.
XRPL Urges Node Operators to Upgrade to xrpld 3.2.1 After Validator Manifest Flood
ChainGPTShare
Summary
Ripple’s engineering team pushed a network upgrade to xrpld v3.2.1 after a validator manifest flood on July 31. The blockchain upgrade introduces limits on untrusted manifest data to prevent resource exhaustion. Operators must restart in two steps after applying the patch. No funds were lost, and consensus remained intact. A technical review is underway. Regular users don’t need to act.
Source:Show original
Disclaimer: The information on this page may have been obtained from third parties and does not necessarily reflect the views or opinions of KuCoin. This content is provided for general informational purposes only, without any representation or warranty of any kind, nor shall it be construed as financial or investment advice. KuCoin shall not be liable for any errors or omissions, or for any outcomes resulting from the use of this information.
Investments in digital assets can be risky. Please carefully evaluate the risks of a product and your risk tolerance based on your own financial circumstances. For more information, please refer to our Terms of Use and Risk Disclosure.