Skip to content
Fencer Intel
medium 4.0

CVE-2026-29795 json

stellar-xdr: `StringM::from_str` bypasses max length validation

published 8mo ago modified 4mo ago also GHSA-x57h-xx53-v53w , EUVD-2026-10071

cvss
4.0
version 3.1, CNA
cisa kev
Not listed
not in CISA's catalog
epss
0.2%
EPSS 0.2% chance of exploitation in 30 days, percentile 13%
public exploits
0
none known

Summary

stellar-xdr is a library and CLI containing types and functionality for working with Stellar XDR. Prior to version 25.0.1, StringM::from_str does not validate that the input length is within the declared maximum (MAX). Calling StringM::<N>::from_str(s) where s is longer than N bytes succeeds and returns an Ok value instead of Err(Error::LengthExceedsMax), producing a StringM that violates its length invariant. This affects any code that constructs StringM values from string input using FromStr (including str::parse), and relies on the type's maximum length constraint being enforced. An oversized StringM could propagate through serialization, validation, or other logic that assumes the invariant holds. This issue has been patched in version 25.0.1.

Patch / fix

Is CVE-2026-29795 in your dependencies? Fencer shows which of your repositories are affected as soon as an advisory lands, and opens the fix as a pull request.

Check with Fencer

CISA SSVC

Exploitation
none
Automatable
no
Technical impact
partial
Assessed
8mo ago

Exploit prediction

0.22% chance of exploitation in the next 30 days, higher than 13% of all scored CVEs (FIRST EPSS, 2026-11-09).

CVSS scores

assigned by version score vector
CNA 3.1 4.0 CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N
NVD 3.1 7.5 CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N
GitHub 3.1 4.0 CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

Affected packages

ecosystem package affected fixed in
crates.io stellar-xdr
<25.0.1
25.0.1

Affected products

  • stellar rs-stellar-xdr

Classification

Weakness
  • CWE-770 Allocation of Resources Without Limits or Throttling

References

Sources

Fencer Intel keeps one entry per vulnerability: the CVE id wins, then GHSA, and records that alias each other are merged, except that two CVEs always keep separate entries. The same data is available as JSON.