Investigate in your agent.

Turn this advisory into a focused investigation. Ask your agent to check your project’s versions, explain the evidence, and suggest a compatible fix.

Your agent needs remote MCP support and access to https://cve.new/mcp.

Read the setup guide

Skip to content
Check your stack
CVE-2026-61694low3.7

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

Impact

go-xrpl versions through 0.0.0-20260618134614-cb77d640ee26 have an integer overflow weakness in ParseMPTAmountBinary, silently decoding large positive MPT amounts as negative. This affects downstream calculations. Local access is required.

Summarized by @cf/meta/llama-3.3-70b-instruct-fp8-fast. Verify details against the original sources.

Affected packages

This source has no supported package-version data for matching. You can read the advisory here, but this record alone cannot power a dependency check.

Affected products

Vendor version evidence. Product records are separate from automatic dependency matching.

LeJamon · GitHub_M

go-xrpl

1 range

Compare with this publisher’s ranges. This does not inspect your installation.

affected

<= 0.0.0-20260618134614-cb77d640ee26

unaffected

unknown

Other versions: unknown

Original source description

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.

Inside the record

Evidence available

Package identity · not supplied
Version evidence
Remediation guidance · not supplied
Weakness classification
Additional publishers · not supplied

Describes the evidence in this view, not whether the product is safe.

Original records

CVE-2026-61694

View the latest unmodified CVE JSON from the official source. It may be newer than this imported page.

cve.new JSON →

Underlying weaknesses

The source’s classification of what caused the vulnerability.

CWE-190 ↗

CWE-190: Integer Overflow or Wraparound

GitHub_M

Related →
Contributing organizations · 1
GitHub_M

Assigning organization

2026-10-30

What changed

Follow changes
No substantive changes have been recorded here yet. History starts when cve.new observes a change after tracking is enabled; earlier edits are not reconstructed.

Large field values are marked as truncated previews. Original source snapshots remain retained.

References

3 sources