Ripple’s XRP Ledger Pushes Critical xrpld Patch After Node Performance Attack

The XRP Ledger deployed the xrpld 3.2.1 hotfix on July 31 after a validator manifest flood was discovered affecting network nodes. Ripple Director of Engineering Vijay Khanna later issued an urgent notice on Aug. 1–2, advising all XRPL node operators to upgrade as soon as possible.

The network remained stable throughout the incident, with no confirmed asset losses and no failures in the consensus process. However, nodes running older software versions remain at risk of resource exhaustion until operators complete the required two-step update process.

The announcement came as XRP dropped 1.5% over the previous 24 hours, falling from $1.10 to $1.06, while daily trading volume reached about $791 million. The move added to XRP’s recent decline, with the asset down roughly 4% over the last week.

How the XRPL Manifest Flood Issue Worked

The vulnerability was tied to the way XRPL nodes handled validator manifests. Before the release of version 3.2.1, nodes could receive, cache, and rebroadcast unlimited numbers of manifests associated with unknown validator keys, with no effective restrictions on the amount of data stored or processed.

Attackers could exploit this behavior by generating large volumes of unnecessary manifest records, forcing affected nodes to consume additional memory, storage, and bandwidth while handling data that had no useful role in network operations.

The event was considered a resource exhaustion attack similar to a denial-of-service attempt, rather than a direct threat to the XRP Ledger’s consensus system. Although infrastructure resources could be strained, transaction validation and ledger agreement continued without interruption.

XRPL developers confirmed that the issue was connected to validator manifest processing within XRPLF nodes. However, the full technical details of the exploit, including the attacker’s exact method and the total amount of malicious activity, have not yet been disclosed.

XRPL Operations is expected to release a comprehensive post-mortem covering the incident, attack behavior, traffic patterns, and any additional security measures introduced afterward.

The vulnerability highlights a wider challenge in blockchain security: components that support the network but do not participate directly in consensus can still become attack targets when data handling mechanisms lack sufficient controls.

xrpld 3.2.1 Adds Multiple Security Limits

The xrpld 3.2.1 upgrade introduces four major protections aimed at preventing future validator manifest abuse.

The update now blocks oversized manifests before they are completely decoded, places limits on the number of manifests accepted in each network message, reduces the amount of manifest data shared with newly connected peers, and caps the cache for unknown validator-key manifests at 100 entries.

The patch also changes how unknown validator manifests are stored by preventing them from being saved to disk. As a result, any malicious manifest data collected before the update will be removed after a restart instead of remaining on the system.

Due to this change, node operators must complete a two-step upgrade procedure.

Operators should first install xrpld 3.2.1 and allow the server to operate for one to two minutes. After that, they must restart the server a second time to remove any older manifest data retained before the patch.

Skipping the second restart may leave previously stored flood-related information intact and prevent the upgrade from fully resolving the issue.

Node operators should also confirm that their systems trust Ripple’s current GPG signing key, which was rotated on Feb. 18, 2026. Without the updated key, automated upgrade processes could fail without clearly indicating the problem.