go-xrpl CVE-2026-61694

Exploitation requires a 33-byte MPToken (MPT) amount field whose 8-byte magnitude is at least 2^63 (0x8000000000000000 or higher) to be fed to one of the two internal decoders: ParseMPTAmountBinary in internal/ledger/state/ripple_state.go (reached via ParseEscrow for sfAmount fields in escrow ledger entries) or readMPTAmount in internal/tx/ledgerfields/decode_stream.go. The exploitation is strongly LIMITED by the fact that such a magnitude exceeds rippled's maximum valid MPT amount (maxMPTokenAmount = 2^63-1), so a conforming XRPL network will not normally emit it - the attacker must supply crafted/malformed binary ledger or transaction data (reflected in AC:H). It is further limited in scope: the public codec codec/binarycodec/types/amount.go already rejects these values, so only consumers using the two internal decoders are affected. Impact is integrity-only (wrong amount, node/rippled divergence); there is no confidentiality or availability effect and no authentication is required to submit the data.

This is a genuinely low-priority issue consistent across all available signals. The CVSS base score is 3.7 (CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:N): network vector but high attack complexity, no privileges or user interaction, no confidentiality or availability impact, and only low integrity impact. The vuln.today Decision label is 'monitor,' the lowest urgency tier, which aligns with the score. No CISA KEV listing and no EPSS score are present in the input, so there is no signal of active or probable exploitation; absence of these is not evidence of safety but gives no cause for escalation. The published material includes a byte-level reproducer blob and a Zorya concolic-execution harness that independently identified the triggering byte (0x80), plus regression tests in the fix commit - so a public proof-of-concept reference exists, though it is a reproducer demonstrating the int64 wrap, not a verified working remote exploit. The AC:H is justified by mechanism: the flaw only triggers when an MPT magnitude of at least 2^63 reaches the internal decoder, a value that exceeds rippled's maxMPTokenAmount (2^63-1) and that a conforming XRPL network would not normally produce, so reaching the code path requires out-of-range/malformed ledger data. The real-world consequence is correctness/consensus divergence (a go-xrpl node interpreting an escrow MPT amount differently from rippled), not direct compromise. Net: a real correctness bug worth patching, but low operational risk and no indication of a priority emergency.

A malformed or hostile MPT amount whose magnitude is at least 2^63 reaches a go-xrpl node - for example a 33-byte sfAmount in an escrow entry parsed by ParseEscrow. The internal ParseMPTAmountBinary calls num.Int64() without a 63-bit check, so the positive magnitude silently two's-complement-wraps into a large negative MPTAmount and is stored without error, and the streaming readMPTAmount similarly surfaces over-limit values as bogus decimal strings; downstream calculations and the node's interpretation of the entry then diverge from rippled. A reproducer blob and a Zorya concolic harness are published in the GHSA advisory, but no weaponized exploit; the AV:N/AC:H rating reflects that reaching the path requires crafted out-of-range data.