← XRP Ledger Critical Mint Vulnerability (October 2026)1 decision on this page
Audit log
Every state-changing event for XRP Ledger Critical Mint Vulnerability (October 2026): moderation decisions on community submissions, plus corrections and updates from the news pipeline. URL-based decisions are designed to carry three independent witnesses — the original source, an Internet Archive snapshot, and a Solana memo signed by our publicly-disclosed publisher key. Archive coverage is still being backfilled, so each decision below reports its own snapshot status rather than assuming one exists.
- #1publishby system:backfill2026-10-13 12:04:59ZScore: ? → ? (no score change)anchoranchored
- chain
- ●mainnet-betaslot 456,435,844
- sig
3wc7pjX1pqNZ…svgU77Ngexplorer ↗- hash
EwMqRij5furJ…zpyk7Kk3sha256 → base58
verifying row…full verify ↗canonical bytes (11342 B) ▸
{"actor":"system:backfill","investigation_id":"0a499fa3-9fec-4d36-ae53-06f983c2710a","kind":"publish","page_slug":"xrp-ledger-critical-mint-vulnerability-october-2026","published_at":"2026-10-13T12:04:59.819Z","sequence_num":1,"snapshot":{"content_type":"investigation","entity_name":"XRP Ledger Critical Mint Vulnerability (October 2026)","sections":[{"content":"The flaw was located in the XRP Ledger's payment engine, in the code that sums XRP amounts when a single payment transaction draws from multiple offers on the decentralized exchange order book. According to secondary reporting on the disclosure, the engine used a 64-bit integer to total these amounts without an overflow check; if the running total exceeded the maximum value a 64-bit integer can hold, it would wrap around to a much smaller number. Because a 'no XRP created' invariant check reportedly relied on the same unchecked arithmetic, it would not have detected the resulting discrepancy, potentially letting offer owners be paid in full while the payer was charged only the wrapped-around (smaller) total. Multiple outlets describe the underlying code path as having existed since the payment engine was originally built, with some reports dating the flaw to around 2015, though the exact origin year could not be independently confirmed from available sources and should be treated as approximate.","heading":"Nature of the Vulnerability","severity":"critical","sources":[{"credibility":2,"name":"XRP Ledger discloses overflow bug that could have minted XRP beyond its supply cap","type":"news_article","url":"https://cryptobriefing.com/xrp-ledger-overflow-bug-extra-xrp/"},{"credibility":2,"name":"XRPL Patches Decade-Old Bug That Could Have Created New XRP","type":"news_article","url":"https://www.kucoin.com/news/flash/xrpl-patches-decade-old-bug-that-could-have-created-new-xrp"}]},{"content":"The vulnerability was reported through the XRPL Bug Bounty program by researcher Cayden Liao, with assistance credited to an AI tool from Veria Labs, on or around September 22, 2026. Reporting on the exact submission date varies slightly between sources (September 21 versus September 22), reflecting a discrepancy in secondary coverage rather than a confirmed fact. RippleX engineers reproduced the exploit on a standalone test server and escalated the bug's severity rating from an initial 'Major' classification to 'Critical.' Some outlets state the researchers received the bug bounty program's maximum reward, reported as $250,000, though this figure could not be independently verified against an official RippleX or Ripple statement in the sources reviewed and should be treated as a secondary-source claim pending primary confirmation.","heading":"Discovery, Reporting, and Reward","severity":"high","sources":[{"credibility":2,"name":"XRP Ledger Discloses Critical Bug That Could Have Created New XRP","type":"news_article","url":"https://www.kucoin.com/news/flash/xrp-ledger-discloses-critical-bug-that-could-have-created-new-xrp"},{"credibility":2,"name":"XRP Ledger: payment engine overflow and the role of AI","type":"news_article","url":"https://www.noze.it/en/insights/xrpl-overflow-ai-agent/"}]},{"content":"RippleX issued an emergency server release, xrpld version 3.4.1, on September 25, 2026 — three days after the bug was reported — fixing the overflow. Notably, the fix was deployed as an ordinary server-software update rather than through the XRP Ledger's standard 'amendment' process, which normally requires sustained support above 80% from trusted validators over a period of roughly two weeks before a protocol change takes effect. According to reporting that cited RippleX's own explanation, following the standard amendment process would have required publicly flagging the change while the network remained vulnerable during the voting and activation window, so the team opted for an immediate update instead. More than 80% of default Unique Node List (UNL) validators were reportedly running the patched version within a day of release. RippleX stated that this exceptional response does not change the ledger's established approach to future protocol amendments, but the episode has been described by at least one outlet as raising questions about balancing emergency security response with transparent governance norms for a system that markets itself as decentralized.","heading":"Emergency Patch and Bypass of Amendment Voting","severity":"high","sources":[{"credibility":2,"name":"XRP Ledger emergency patch bypasses standard validator voting process","type":"news_article","url":"https://www.cryptometer.io/news/xrp-ledger-emergency-patch-bypasses-standard-validator-voting-process/"},{"credibility":2,"name":"XRPL Patches Decade-Old Bug That Could Have Created New XRP","type":"news_article","url":"https://www.kucoin.com/news/flash/xrpl-patches-decade-old-bug-that-could-have-created-new-xrp"}]},{"content":"The vulnerability was publicly disclosed on October 9, 2026, roughly two weeks after the patch had already been widely adopted by validators. The XRPL Operations account stated, as quoted in secondary coverage, 'We have found no evidence that this issue was exploited on any public network,' and reporting indicates no unauthorized XRP was created, no funds were lost, and no consensus failures were tied to the bug. Estimates of how much XRP could theoretically have been minted in a single exploit vary widely and are largely unverified: a promotional post from Veria Labs, the firm credited with assisting in the discovery, claimed a figure as high as approximately 18 trillion XRP (roughly 180 times the entire 100 billion supply cap) through a single payment transaction, while official-sourced reporting described the attack as requiring hundreds of deliberately mispriced order-book offers plus a specific payment transaction, at a cost of only a few hundred XRP in largely refundable reserves and ordinary transaction fees. Because the larger figure originates from the discoverer's own marketing material rather than an independently audited source, it should be treated as an unverified, low-confidence claim.","heading":"Public Disclosure and Exploitation Status","severity":"medium","sources":[{"credibility":2,"name":"XRP Ledger Bug Minted XRP Overflow","type":"news_article","url":"https://news.bitcoin.com/featured/xrp-ledger-bug-minted-xrp-overflow/"},{"credibility":3,"name":"XRP Stays Above Key Support Even as a Decade-Old Ledger Bug That Could Have Minted 18 Trillion Tokens Is Revealed","type":"news_article","url":"https://egamers.io/?p=122994"}]},{"content":"Alongside the payment-engine overflow, XRPL maintainers disclosed a separate, lower-severity issue affecting the ledger's Batch transaction feature that could have disrupted transaction validation. A related signature-validation flaw in the Batch amendment's logic had been separately identified and fixed earlier, in February 2026, by researchers Pranamya Keshkamat and Cantina AI, while the Batch feature was still in its amendment-voting stage and before it affected mainnet; no funds were at risk in that earlier instance because the amendment had not yet activated. The fixBatchV1_2 amendment referenced in connection with the October disclosure is reported to have gone live on the same day as the public disclosure, October 9, 2026.","heading":"Related, Separate Issue: Batch Transaction Feature","severity":"low","sources":[{"credibility":2,"name":"XRP Ledger emergency patch bypasses standard validator voting process","type":"news_article","url":"https://www.cryptometer.io/news/xrp-ledger-emergency-patch-bypasses-standard-validator-voting-process/"}]}],"sources_used":[{"credibility":2,"name":"XRP Ledger Discloses Critical Bug That Could Have Created New XRP","type":"news_article","url":"https://www.kucoin.com/news/flash/xrp-ledger-discloses-critical-bug-that-could-have-created-new-xrp"},{"credibility":2,"name":"XRP Ledger discloses overflow bug that could have minted XRP beyond its supply cap","type":"news_article","url":"https://cryptobriefing.com/xrp-ledger-overflow-bug-extra-xrp/"},{"credibility":2,"name":"XRP Ledger Bug Minted XRP Overflow","type":"news_article","url":"https://news.bitcoin.com/featured/xrp-ledger-bug-minted-xrp-overflow/"},{"credibility":2,"name":"XRP Ledger emergency patch bypasses standard validator voting process","type":"news_article","url":"https://www.cryptometer.io/news/xrp-ledger-emergency-patch-bypasses-standard-validator-voting-process/"},{"credibility":2,"name":"XRPL Patches Decade-Old Bug That Could Have Created New XRP","type":"news_article","url":"https://www.kucoin.com/news/flash/xrpl-patches-decade-old-bug-that-could-have-created-new-xrp"},{"credibility":2,"name":"XRP Ledger: payment engine overflow and the role of AI","type":"news_article","url":"https://www.noze.it/en/insights/xrpl-overflow-ai-agent/"},{"credibility":3,"name":"XRP Stays Above Key Support Even as a Decade-Old Ledger Bug That Could Have Minted 18 Trillion Tokens Is Revealed","type":"news_article","url":"https://egamers.io/?p=122994"},{"credibility":2,"name":"XRP Ledger Closes a 2015 Flaw That Could Create XRP Out of Nothing: What It Means for Your Coins","type":"news_article","url":"https://cryptoticker.io/en/xrpl-payment-engine-overflow-patch/"}],"summary":"In October 2026, the XRP Ledger development community disclosed a critical integer-overflow bug in the rippled/xrpld payment engine that could reportedly have allowed an attacker to mint spendable XRP beyond the ledger's 100 billion token supply cap. The flaw, reported through the XRPL Bug Bounty program on September 22, 2026, was patched in an emergency release (xrpld 3.4.1) on September 25, 2026, before being publicly disclosed on October 9, 2026. RippleX and the XRPL Operations team said they found no evidence the bug was ever exploited on a public network, though the episode drew scrutiny for bypassing the ledger's normal amendment-voting process and for the age of the flaw, which multiple outlets traced back roughly a decade.","timeline":[{"date":"2026-09","date_evidence":"Sept. 22: Findings submitted through the bug bounty program.","date_original":"2026-09-22","event":"Researcher Cayden Liao, with assistance from Veria Labs' AI tooling, reported the payment-engine overflow vulnerability through the XRPL Bug Bounty program.","source":"News.Bitcoin.com","source_url":"https://news.bitcoin.com/featured/xrp-ledger-bug-minted-xrp-overflow/"},{"date":"2026-09","date_evidence":"the fix shipped in xrpld version 3.4.1, released on September 25","date_original":"2026-09-25","event":"RippleX shipped an emergency patch, xrpld 3.4.1, fixing the overflow; over 80% of default UNL validators adopted it quickly, bypassing the standard amendment-voting process.","source":"CryptoBriefing / News.Bitcoin.com","source_url":"https://cryptobriefing.com/xrp-ledger-overflow-bug-extra-xrp/"},{"date":"2026-10","date_evidence":"Oct. 9: Public disclosure. The fixBatchV1_2 amendment also went live that day.","date_original":"2026-10-09","event":"The XRP Ledger team publicly disclosed the critical payment-engine overflow vulnerability, roughly two weeks after it had already been patched network-wide.","source":"News.Bitcoin.com","source_url":"https://news.bitcoin.com/featured/xrp-ledger-bug-minted-xrp-overflow/"}]},"v":1}Verify offline (run on your own machine)python -m src.verify_decision d0d4ac9b-372a-47f9-8916-f0711a3007e2
How verification works. The “Row integrity” check above is computed in your browser — your machine recomputes the SHA-256 of the canonical bytes and compares against the stored hash. No avoid.net server can fake that check. The “full verify” link goes one level deeper: your browser fetches the on-chain transaction from a Solana RPC node and confirms the same hash is in the memo. If you don’t want to trust either avoid.net or the public RPC, run the CLI verifier on your own machine —
python -m src.verify_decision <event_id>.