XRP Ledger Issues Hotfix for Manifest Flood Vulnerability

The XRP Ledger development team has released xrpld version 3.2.1, a hotfix addressing a vulnerability that could lead to a manifest flood attack, potentially exhausting node resources. The issue was detected on July 31, prompting an urgent call from Ripple Director of Engineering Vijay Khanna for node operators to upgrade their systems.

The vulnerability exploited how XRP Ledger nodes handled validator manifests. Previously, nodes could accept, cache, and rebroadcast an unlimited number of manifests tied to unknown validator keys, consuming significant memory, disk space, and bandwidth as nodes processed data they would not act upon. This mechanism is characterized as a denial-of-service resource drain rather than a consensus attack, meaning transaction processing remained unaffected, but unprotected infrastructure faced exposure.

According to Khanna, the hotfix introduces four key protections: rejecting oversized manifests, capping incoming manifest batches, limiting manifest data shared with new peers, and capping the unknown-key manifest cache at 100 entries. Furthermore, unknown validator manifests are no longer written to disk, aiding in the clearance of pre-patch flood data upon restart.

Node operators are required to follow a specific two-step upgrade process. After installing version 3.2.1, servers must run for one to two minutes before a second restart. This second restart is crucial for purging any manifests retained from before the patch; omitting it leaves stale flood data in place. Operators should also suggest their systems trust Ripple’s current GPG signing key, rotated on February 18, 2026, to prevent silent failures in automatic upgrades.

Ordinary XRP holders need not take action, as the incident did not result in reported fund losses or consensus failures. However, the urgency for node operators is heightened by potential upgrade adoption lag. The XRP Ledger added nearly 490,000 new accounts in the first half of 2026, as per supplementary data from Coinpaper, bringing the total to over 8.4 million. This growth underscores the increasing necessity of robust infrastructure hardening.

As of publication, the root cause and full exploitation details of the manifest flood attack remain publicly undisclosed. A technical post-mortem from XRPL Operations is expected to provide further clarification on attacker behavior, traffic volumes, and additional hardening steps. This incident aligns with a broader pattern where unbounded auxiliary data channels can become leverage points in blockchain networks, even when consensus logic holds.

The network security response, including a targeted hotfix and clear operator instructions, is considered operationally sound. Nevertheless, the incident highlights that as the XRP Ledger scales, robust infrastructure hardening is becoming a structural necessity. Institutional developments, such as Aviva’s tokenized liquidity fund on XRPL and growing enterprise adoption, increase the stakes for operators delaying necessary patches.

Why This Matters

The materials describe a narrow update: A vulnerability in the XRP Ledger’s handling of validator manifests allowed an attacker to flood nodes with junk data, consuming excessive memory, disk space, and bandwidth. Root cause and full exploitation details of the manifest flood attack have not been publicly disclosed as of publication.

Broader Context

Source materials place the factual news in this context: The XRP Ledger released xrpld 3.2.1 on July 31 after a validator manifest flood was detected hitting nodes that same day, with Ripple Director of Engineering Vijay Khanna issuing an urgent call on August 1–2 for all node operators to upgrade immediately.

Comments

Leave a Reply

Your email address will not be published. Required fields are marked *