CVE-2026-61694: go-xrpl: ParseMPTAmountBinary: positive MPT amount silently decoded as negative (int64 wrap)

Published Oct 30, 2026

Updated

go-xrpl is a Go implementation of the XRP Ledger protocol. In versions through the June 18, 2026 revision identified by the advisory, ParseMPTAmountBinary in internal/ledger/state/ripplestate.go converts the eight-byte MPT magnitude using num.Int64() without checking that it fits in 63 bits. A positive magnitude of at least 2^63 silently wraps into a negative amount without an error. ParseEscrow passes 33-byte sfAmount fields to the parser and stores MPTRaw() in EscrowData.MPTAmount, causing incorrect downstream calculations and divergence from rippled's interpretation of the same escrow entry. Independently, readMPTAmount in internal/tx/ledgerfields/decodestream.go accepts over-limit magnitudes and surfaces large decimal strings without enforcing the maximum signed 64-bit value. The public codec in codec/binarycodec/types/amount.go already rejects these values, leaving the internal decoders inconsistent with that safe path. A source fix is available in commit 9dbd3935ed6c54f0232f2291edf9c012a0900dd5.

Event History

Oct 30, 2026

CVE Published

via MITRE·07:55 PM

Data Sourced

via MITRE·07:55 PM

DescriptionSeverityWeakness

Data Sourced

via NVD·08:17 PM

DescriptionSeverityWeakness

Frequently Asked Questions

Which parsing paths require attention?

The affected internal paths are ParseMPTAmountBinary as reached by ParseEscrow for 33-byte sfAmount fields, and readMPTAmount in the transaction ledger-field decoder. The public codec path in codec/binarycodec/types/amount.go already rejects magnitudes that exceed the signed 64-bit limit.

What input is needed to trigger incorrect amount handling?

An input must contain a positive MPT magnitude of at least 2^63. In the escrow path, this can cause the parsed value stored in EscrowData.MPTAmount to become negative; the stream decoder instead accepts the over-limit magnitude and returns a large decimal string.

What can be done before the source fix is deployed?

Do not rely on the affected internal decoders for MPT amounts with untrusted binary input. Reject positive MPT magnitudes at or above 2^63 before those paths are reached, or use the public codec path that already enforces the signed 64-bit limit.

How can teams check for potentially affected processing?

Review uses of ParseEscrow, ParseMPTAmountBinary, and readMPTAmount in versions through the advisory's June 18, 2026 revision. Parsed escrow entries containing a positive MPT magnitude of at least 2^63 may have produced a negative MPTAmount and downstream calculations inconsistent with rippled.

What fix is available?

A source fix is available in commit 9dbd3935ed6c54f0232f2291edf9c012a0900dd5. The fix should be applied to ensure internal decoding rejects or otherwise handles values outside the signed 64-bit range consistently.

CVE-2026-61694: go-xrpl: ParseMPTAmountBinary: positive MPT amount silently decoded as negative (int64 wrap)

Event History

Frequently Asked Questions

Which parsing paths require attention?

What input is needed to trigger incorrect amount handling?

What can be done before the source fix is deployed?

How can teams check for potentially affected processing?

What fix is available?

Company

Resources

Contact

Frequently Asked Questions

Which parsing paths require attention?

What input is needed to trigger incorrect amount handling?

What can be done before the source fix is deployed?

How can teams check for potentially affected processing?

What fix is available?