Skip to content

soroban-sdk has overflow in Bytes::slice, Vec::slice, GenRange::gen_range for u64

Moderate severity GitHub Reviewed Published Jan 28, 2026 in stellar/rs-soroban-sdk • Updated Jan 29, 2026

Package

cargo soroban-sdk (Rust)

Affected versions

>= 25.0.0, < 25.0.2
>= 23.0.0, < 23.5.1
< 22.0.9

Patched versions

25.0.2
23.5.1
22.0.9

Description

Impact

Arithmetic overflow can be triggered in the Bytes::slice, Vec::slice, and Prng::gen_range (for u64) methods in the soroban-sdk in versions prior to and including 25.0.1.

Contracts that pass user-controlled or computed range bounds to Bytes::slice, Vec::slice, or Prng::gen_range may silently operate on incorrect data ranges or generate random numbers from an unintended range, potentially resulting in corrupted contract state.

Note that the best practice when using the soroban-sdk and building Soroban contracts is to always enable overflow-checks = true. The stellar contract init tool that prepares the boiler plate for a Soroban contract, as well as all examples and docs, encourage the use of configuring overflow-checks = true on release profiles so that these arithmetic operations fail rather than silently wrap. Contracts are only impacted if they use overflow-checks = false either explicitly or implicitly. It is anticipated the majority of contracts could not be impacted because the best practice encouraged by tooling is to enable overflow-checks.

Detail

When compiled with overflow-checks = false (the default for release builds), the bare arithmetic in those functions silently wraps on boundary values like u32::MAX or u64::MAX. This causes the range passed to the host to differ from the caller's intent:

Bytes::slice:

  • Bytes::slice(0..=u32::MAX) — end u32::MAX + 1 wraps to 0, producing slice(0..0) returning empty instead of the full range.
  • Bytes::slice((Bound::Excluded(u32::MAX), Bound::Unbounded)) — start u32::MAX + 1 wraps to 0, producing slice(0..) instead of an empty/invalid range.

Vec::slice:

  • Vec::slice(0..=u32::MAX) — same as Bytes, end wraps to 0, returning empty.
  • Vec::slice((Bound::Excluded(u32::MAX), Bound::Unbounded)) — same as Bytes, start wraps to 0.

Prng::gen_range:

  • Prng::gen_range((Bound::Unbounded, Bound::Excluded(0))) — end 0 - 1 wraps to u64::MAX, producing range 0..=u64::MAX instead of an empty/invalid range.
  • Prng::gen_range((Bound::Excluded(u64::MAX), Bound::Unbounded)) — start u64::MAX + 1 wraps to 0, producing range 0..=u64::MAX instead of an empty/invalid range.

Note that some cases where the overflow was permitted and wrapped on the guest side are caught by the Soroban Env Host and cause a trap host side with error HostError: Error(Object, IndexBounds) object index out of bounds, because the wrapped values create invalid inputs:

  • Bytes::slice(u32::MAX..=u32::MAX) — both start u32::MAX + 1 and end u32::MAX + 1 wrap to 0, producing slice(0..0).
  • Vec::slice(u32::MAX..=u32::MAX) — same as Bytes, both wrap to 0.

Patches

The fix replaces bare arithmetic with checked_add / checked_sub, ensuring overflow traps regardless of the overflow-checks profile setting.

Workarounds

Contract workspaces can be configured with the following profile to enable overflow checks on the arithmetic operations. This is the best practice when developing Soroban contracts, and the default if using the contract boilerplate generated using stellar contract init:

[profile.release]
overflow-checks = true

Alternatively, contracts can validate range bounds before passing them to slice or gen_range to ensure the conversions cannot overflow:

  • Do not pass Bound::Excluded(u32::MAX) or Bound::Included(u32::MAX) to Bytes::slice or Vec::slice.
  • Do not pass Bound::Excluded(u64::MAX) as a start bound or Bound::Excluded(0) as an end bound to Prng::gen_range::<u64>.

References

References

@leighmcculloch leighmcculloch published to stellar/rs-soroban-sdk Jan 28, 2026
Published by the National Vulnerability Database Jan 28, 2026
Published to the GitHub Advisory Database Jan 28, 2026
Reviewed Jan 28, 2026
Last updated Jan 29, 2026

Severity

Moderate

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
Low
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N

EPSS score

Weaknesses

Integer Overflow or Wraparound

The product performs a calculation that can produce an integer overflow or wraparound when the logic assumes that the resulting value will always be larger than the original value. This occurs when an integer value is incremented to a value that is too large to store in the associated representation. When this occurs, the value may become a very small or negative number. Learn more on MITRE.

CVE ID

CVE-2026-24889

GHSA ID

GHSA-96xm-fv9w-pf3f

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.