CVE-2026-29795 Overview
CVE-2026-29795 is an input validation vulnerability in the stellar-xdr library, a Rust library and CLI tool used for working with Stellar XDR (External Data Representation) data types. The vulnerability exists in the StringM::from_str implementation, which fails to properly validate that input string lengths conform to the declared maximum constraint. This allows attackers to create StringM instances that violate their length invariants, potentially leading to downstream integrity issues in serialization, validation, and other processing logic.
Critical Impact
Applications relying on the StringM type's maximum length constraint for data validation may process oversized strings, potentially corrupting serialized data or bypassing security checks that assume the length invariant holds.
Affected Products
- stellar-xdr library versions prior to 25.0.1
- rs-stellar-xdr Rust crate (all versions before 25.0.1)
- Applications using StringM::from_str or str::parse for string validation
Discovery Timeline
- 2026-03-06 - CVE CVE-2026-29795 published to NVD
- 2026-03-09 - Last updated in NVD database
Technical Details for CVE-2026-29795
Vulnerability Analysis
The vulnerability stems from improper input validation in the StringM::from_str trait implementation within the stellar-xdr library. The StringM<N> type is designed to be a bounded string type where N represents the maximum allowable length in bytes. However, the from_str implementation does not properly enforce this constraint.
When calling StringM::<N>::from_str(s) where s contains more than N bytes, the function incorrectly returns an Ok result instead of the expected Err(Error::LengthExceedsMax). This creates a StringM instance that violates its fundamental length invariant—the core guarantee that any StringM<N> instance will contain at most N bytes.
This class of vulnerability is categorized under CWE-770 (Allocation of Resources Without Limits or Throttling), as the implementation fails to enforce the expected resource constraints on string allocation.
Root Cause
The root cause is a missing length validation check in the FromStr trait implementation for the StringM type. The Rust trait FromStr is commonly used via the str::parse() method, making this a widely-used code path for constructing StringM values from string input.
The implementation accepts strings of any length and successfully constructs StringM instances without comparing the input length against the type's declared maximum (MAX). This oversight allows oversized data to bypass the type system's intended safety guarantees.
Attack Vector
The attack vector is local, requiring an attacker to provide crafted string input to an application that uses the vulnerable StringM::from_str method. Exploitation scenarios include:
An attacker could provide an oversized string to any application endpoint that parses user input into StringM types. The oversized StringM value would then propagate through the application's data flow. Downstream components that assume the length invariant holds may exhibit unexpected behavior when processing the oversized data, including:
- Serialization routines producing malformed XDR data
- Validation logic incorrectly passing oversized values
- Buffer size calculations becoming inaccurate
- Data integrity checks failing on peer systems that properly validate length constraints
For technical implementation details, refer to the GitHub Security Advisory GHSA-x57h-xx53-v53w and GitHub Issue #499.
Detection Methods for CVE-2026-29795
Indicators of Compromise
- Applications processing XDR data with string fields exceeding their declared maximum lengths
- Serialization errors or data corruption in Stellar XDR payloads
- Validation failures when exchanging data with systems using patched versions
- Unexpected data truncation or buffer-related issues in downstream processing
Detection Strategies
- Audit application dependencies for stellar-xdr versions prior to 25.0.1
- Review application logs for XDR serialization or deserialization errors
- Implement integrity checks comparing string field lengths against XDR schema constraints
- Use Rust dependency scanning tools (e.g., cargo audit) to identify vulnerable versions
Monitoring Recommendations
- Monitor for anomalous string lengths in XDR data flows
- Implement logging for StringM construction failures after upgrading to catch previously-allowed oversized inputs
- Track data validation errors that may indicate exploitation attempts
- Review application telemetry for unexpected data integrity issues
How to Mitigate CVE-2026-29795
Immediate Actions Required
- Upgrade stellar-xdr to version 25.0.1 or later immediately
- Audit codebases for usage of StringM::from_str or str::parse with StringM types
- Review any data persisted using the vulnerable version for potential integrity issues
- Implement additional input validation as a defense-in-depth measure
Patch Information
The vulnerability has been patched in stellar-xdr version 25.0.1. The fix adds proper length validation to the from_str implementation, ensuring that strings exceeding the declared maximum length correctly return Err(Error::LengthExceedsMax).
The patch is available via the GitHub Commit Update. Users should update their Cargo.toml dependency to require version 25.0.1 or higher.
For additional context on the fix implementation, see GitHub Pull Request #500.
Workarounds
- Implement manual length validation before calling StringM::from_str to reject oversized inputs
- Use alternative construction methods that include explicit length checking
- Add application-level input validation to enforce string length constraints before XDR type construction
- Consider wrapper functions that validate input length against the expected maximum before delegating to from_str
# Update stellar-xdr dependency in Cargo.toml
# Change the version requirement to:
stellar-xdr = ">=25.0.1"
# Then run cargo update to fetch the patched version
cargo update -p stellar-xdr
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

