---
id: "CVE-2026-61694"
kind: "vulnerability"
aliases: ["CVE-2026-61694"]
title: "go-xrpl: MPT amount parsing wraps large values negative, diverging from rippled"
severity: "low"
cvss: 3.7
epss: null
exploited: false
status: "open"
category: "package"
products: []
ecosystems: []
tags: ["go-xrpl", "golang", "package", "xrp-ledger"]
not_affected_if: ["no-escrow-parsing", "public-codec-only"]
published_at: "2026-10-30T20:17:11+00:00"
first_seen_at: "2026-10-30T20:25:38+00:00"
updated_at: "2026-10-30T20:26:56+00:00"
sources: [{"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-61694", "first_seen_at": "2026-10-30T20:25:38+00:00"}]
---

# go-xrpl: MPT amount parsing wraps large values negative, diverging from rippled

go-xrpl is a Go implementation of the XRP Ledger protocol, and its internal MPT amount decoders accept magnitudes of 2^63 or more without checking them. Such values silently wrap into negative amounts, so escrow calculations can differ from rippled's interpretation of the same ledger entry.

_Summary, check and fix written by a model from the sources; labelled as such._

## How to check

- Check whether the project depends on go-xrpl with `go list -m all | grep go-xrpl`
- Look for calls to `ParseMPTAmountBinary`, `ParseEscrow` or `readMPTAmount` in your code
- Compare the go-xrpl version in `go.mod` against the affected revision in the advisory

## Fix

- A source fix exists in commit 9dbd3935ed6c54f0232f2291edf9c012a0900dd5; the sources do not give a released version number, so unknown

## Timeline

- 2026-10-30T20:25:38+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-61694

## From the sources

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/ripple_state.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/decode_stream.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.

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_