-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 0xCERT Security Advisory 0xCERT-2026-0236 ============================================================ Advisory-ID: 0xCERT-2026-0236 Severity: Critical Published: 2026-10-09T00:00:00.000Z Updated: 2026-10-13T16:38:52.129Z Chains: Other / Multi-chain URL: https://www.0xcert.com/advisory/0xCERT-2026-0236 Title: xrpld 3.4.0 and earlier: payment-engine integer overflow allowed minting XRP; Batch wrapper validation gap Summary - ------- 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. Details - ------- 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. References - ---------- - - https://xrpl.org/blog/2026/vulnerabilitydisclosurereport-bug-20261009 - - https://xrpl.org/blog/2026/xrpld-3.4.1 Verify with the 0xCERT OpenPGP key: https://www.0xcert.com/pgp.asc Fingerprint: 5F94 3ED1 1E50 CF31 2128 C493 CCC7 D9EC 9415 723D -----BEGIN PGP SIGNATURE----- wrsEARYKAG0FgmroItgJEDe9Tbcr+ZxrRRQAAAAAABwAIHNhbHRAbm90YXRp b25zLm9wZW5wZ3Bqcy5vcmftlPeMlJsmSruZVRYt0jF8IYRs3zM7VRrcgh9p M4DeZhYhBGCkkFZbJcT5QWu27ze9Tbcr+ZxrAABuNQD/aRWRKA+jlr3um4Bg v2f7+Nm9aNGaXvsHHpgtVAHCuOYA/iU9mdyOoJo+4BeL4afdBPXX6EjNS4lJ OB8uELRkwMQK =ahJu -----END PGP SIGNATURE-----