XRP Ledger ships 3.2.1 hotfix to stop validator manifest flood

The XRP Ledger shipped xrpld 3.2.1 on Aug. 1 after a validator-manifest flood strained peer infrastructure, with consensus closing ledgers normally throughout.

"Node operators, please upgrade to 3.2.1 asap. It has a hotfix that prevents the manifest flood attack," Vijay Khanna, Director of Engineering at Ripple, said on X on Aug. 1.

The hotfix adds four limits: individual manifests exceeding expected encoded size are rejected before decoding; incoming batches with excessive untrusted manifests are discarded; bulk manifest greetings to new peers are capped; and the unknown-key manifest cache is hard-capped at 100 entries. Untrusted manifests are no longer written to disk.

The incident affected peer-layer message propagation rather than balances or ledger rules. XRP traded at $1.07, down 1 percent in 24 hours, with daily volume of $791 million, as the network added nearly 490,000 new accounts in H1 2026 to push total accounts past 8.4 million.

How the Flood Exploited Unbounded Manifest Handling

Validator manifests link a validator's permanent master key to its temporary signing key, allowing operators to rotate working keys while keeping master credentials offline. Before the patch, nodes accepted, stored, and rebroadcast unlimited manifests tied to unknown validator keys, creating a resource-exhaustion vector.

An attacker could generate junk manifests at scale, forcing nodes to burn memory, disk space, and bandwidth processing data they would never act on. The mechanism is closer to a denial-of-service resource drain than a consensus attack — transaction processing was never disrupted, but unprotected infrastructure faced real exposure.

The development team confirmed the problem was tied to how XRPLF nodes handled validator manifests. A technical post-mortem is forthcoming from XRPL Operations, which should clarify attacker behavior, traffic volumes, and any additional hardening steps.

Two-Step Restart and GPG Key Verification

Node operators were instructed to install 3.2.1, wait one to two minutes, confirm xrpld is running, then restart again. The second restart purges any manifests retained from before the patch, since unknown-key manifests are no longer persisted to disk.

Administrators using packaged installations should verify Ripple's current software-signing key. Ripple rotated the GPG key used to sign xrpld packages on Feb. 18, 2026. Systems that have not trusted the replacement key may fail to receive automatic upgrades.

The upgrade adoption lag adds urgency: xrpld v3.2.0, the larger June 15 release that renamed the reference server and required infrastructure config changes, spread faster among validators than across the broader node network. A cohort of operators may still be running older versions that are now doubly exposed.

The hotfix introduces no network amendment and does not change transaction-processing rules. It establishes firm limits on untrusted peer data before that information reaches decoding, rebroadcasting, caching, or permanent storage. Exchanges, custodians, wallet backends, and data providers running their own XRPL servers must complete the upgrade; ordinary XRP holders do not need to move funds or change keys.

This article is for informational purposes only and does not constitute investment advice.