Urgent XRPL Update: Ripple Director Urges Node Operators to Install Critical Fix

Vijay Khanna, Director of Engineering at Ripple, sent an important message to XRP Ledger node operators. The advisory pertains to the recent XRPL release, version 3.2.1, which contains an essential fix for the network.

Khanna urges validators to upgrade to 3.2.1 as soon as possible, saying that it contains a hotfix that prevents the manifest flood attack.

A manifest flood was observed on the XRPL network on Friday, July 31, but is now fixed by xrpld version 3.2.1.

Nodes previously accepted, stored, and rebroadcast an unlimited number of manifests from unknown validator keys; version 3.2.1 adds four limits, which include a size cap per manifest where any single manifest larger than expected is rejected; a receive cap where incoming batches over the limit are discarded instead of breaking the peer connection; a send cap where the bulk manifest greeting sent to each new peer is now bounded; and fourth, a cache cap where once 100 unknown keys are held, new ones are refused. Manifests are also no longer persisted from unknown keys to disk, so a flood cannot survive a restart.

Node operators are urged to follow the process by updating normally to XRPL 3.2.1; waiting one to two minutes and confirming xrpld is running; and lastly, restarting xrpld again, which is very essential.

About XRPL 3.2.1

In a detailed blog post, Xora Finance explains what changes with the xrpld 3.2.1 version.

An XRPL validator has two identities, each with a separate job. A stable master key determines who the validator is. A changeable ephemeral key signs daily validation messages. A validator manifest is a master-key-signed statement that links these identities together.

Prior to 3.2.1, a peer could send several manifests that were structurally correct and cryptographically valid even when their master keys were not listed.

XRPL 3.2.1 hardens validator manifest propagation by rejecting oversized objects earlier, caps untrusted processing and retained identities, limits message size, restricts relaying of fresh untrusted identities, and keeps untrusted gossip out of persistent storage.