Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🦀 crates.io

GHSA-96xm-fv9w-pf3f

MEDIUM

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

Also known asCVE-2026-24889
Published
Jan 28, 2026
Updated
Feb 3, 2026
Affected
3 pkgs
Patched
3 / 3
Exploits
None indexed

EPSS Exploitation Probability

via FIRST.org ↗
0.4%probability of exploitation in next 30 days
Lower Risk27th percentile+0.33%
0.00%0.28%0.57%0.85%0.0%0.4%Feb 26May 26Jun 26

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

Blast Radius

3 pkgs affected
🦀soroban-sdk🦀soroban-sdk🦀soroban-sdk

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.

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

Affected Packages

3 total 3 fixed
EcosystemPackageVulnerable rangeFix
🦀crates.iosoroban-sdk25.0.0&&< 25.0.225.0.2
🦀crates.iosoroban-sdk23.0.0&&< 23.5.123.5.1
🦀crates.iosoroban-sdkall versions22.0.9

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for soroban-sdk. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update soroban-sdk to 25.0.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-96xm-fv9w-pf3f is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-96xm-fv9w-pf3f is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-96xm-fv9w-pf3f. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### 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 `
O3 Security · Impact-Aware SCA

Is GHSA-96xm-fv9w-pf3f in your dependencies?

O3 detects GHSA-96xm-fv9w-pf3f across crates.io dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.