Ripple Issues Critical XRPL 3.2.1 Hotfix for Manifest Flood Attacks
In brief
- Ripple engineering director Vijay Khanna issued urgent upgrade call for XRPL node operators to version 3.2.1
- Version 3.2.1 hotfix prevents manifest flood attacks following July 31 incident on XRP Ledger network
- Update adds four manifest handling limits: size caps, receive caps, send caps, and cache limits
The Attack Vector
Before version 3.2.1, the XRPL accepted, stored, and rebroadcast an unlimited number of manifests from unknown validator keys. A manifest flood was observed on the XRPL network on Friday, July 31, exposing a vulnerability in how the network handled these messages.
To understand the risk, it helps to know how XRPL validators work. An XRPL validator has two identities: a stable master key that determines the validator's identity and a changeable ephemeral key that signs daily validation messages. Prior to the fix, a peer could send manifests that were structurally correct and cryptographically valid even when their master keys were not listed on the network—a loophole attackers exploited.
What Version 3.2.1 Changes
Version 3.2.1 adds four limits to manifest handling: a size cap per manifest, a receive cap for incoming batches, a send cap for bulk manifest greetings, and a cache cap for unknown keys. The update also introduces a key structural change: manifests from unknown keys are no longer persisted to disk in version 3.2.1, preventing a flood from surviving a restart.
This multi-layered approach ensures that even if an attacker floods the network with crafted manifests, the attack cannot accumulate or persist across node restarts.
Operator Action Required
Node operators are urged to update to XRPL 3.2.1, wait one to two minutes to confirm xrpld is running, and restart xrpld. The upgrade process is straightforward but time-sensitive—Khanna's message emphasizes the importance of moving quickly to close the attack vector network-wide.
