Skip to content
Latest alertPremia options vaults on Arbitrum drained of about $400k-$465k via empty option pools and flash loans
0xCERT
All advisories
Critical0xCERT-2026-0236·

xrpld 3.4.0 and earlier: payment-engine integer overflow allowed minting XRP; Batch wrapper validation gap

An integer overflow in the xrpld payment engine (3.4.0 and earlier) let a crafted set of offers plus one payment mint spendable XRP. A Batch wrapper validation gap also risked a consensus halt. Both are fixed in xrpld 3.4.1, and no exploitation was found. Operators must run 3.4.1 or later; older servers are now amendment blocked.

Vuln-watch · relayed from a public source; see Source & attribution below

Affected chainsOther / Multi-chain

Summary

On 2026-10-09 the XRP Ledger developers published a vulnerability disclosure report for two bugs fixed in xrpld 3.4.1 (released 2026-09-25 as an emergency release). The first is an integer overflow in the payment engine that could be exploited to create XRP from nothing. The second is a missing check on how Batch (XLS-56) inner transactions are wrapped, which could cause malformed ledger records and a consensus disagreement between server versions.

Affected

  • Payment engine XRP overflow: xrpld 3.4.0 and earlier (the report says the bug was likely present since the current payment engine was written in 2015)
  • Batch inner transaction wrapper validation: xrpld 3.3.0 and 3.4.0 (BatchV1_1 amendment, not activated on Mainnet at the time of the finding)
  • Fixed in xrpld 3.4.1. The overflow fix applies as soon as a server upgrades. The Batch fix is the fixBatchV1_2 amendment, which was enabled on Mainnet on 2026-10-09.

Impact

Payment engine overflow: an attacker could place a few hundred offers selling a tiny amount of a token for very large amounts of XRP, then send one payment that consumes them all. The 64-bit sum of the amounts wrapped around, so offer owners were credited in full while the buyer paid only the wrapped total. The "no XRP created" invariant used the same unchecked arithmetic and did not detect the mint. The cost was a few hundred XRP in reserves plus fees. The source rates this critical and states it found no evidence of exploitation on any public network. The fix deliberately shipped without the amendment process because of its severity. Batch wrapper gap: a hand-crafted Batch transaction could wrap inner transactions in a field other than RawTransaction. The transaction would be accepted and permanently recorded, breaking parsers and SDKs that expect RawTransaction (xrpl.js, xrpl-py, xrpl4j). On a mixed 3.3.0/3.4.0 network it could also stall ledger validation. The source states no loss of funds or consensus failure occurred.

Recommended actions

  • Upgrade every xrpld server to 3.4.1 or later. Servers on older versions are now amendment blocked and cannot stay in sync with Mainnet.
  • Indexers and tooling that parse Batch transactions should make sure they handle the RawTransaction wrapper as specified.

Source & attribution

This 0xCERT advisory summarises a disclosure by the XRP Ledger developers (XRPL Foundation and RippleX Engineering): https://xrpl.org/blog/2026/vulnerabilitydisclosurereport-bug-20261009. The XRP overflow was reported by Cayden Liao and Veria AI through the XRPL bug bounty program. The Batch issue originated as finding F48 in the Sherlock Attackathon and was re-verified by Denis Angell (XRPL Foundation); Mayukha Vadari (RippleX) identified the consensus risk. Details may change; refer to the original source for the authoritative record.

OpenPGP-signed. The signed text of this advisory verifies against the 0xCERT key CCC7 D9EC 9415 723D.

Published 2026-10-09 · last updated 2026-10-13

curl -s https://www.0xcert.com/pgp.asc | gpg --import && curl -s https://www.0xcert.com/advisory/0xCERT-2026-0236/signed.txt | gpg --verify