CVE-2026-24889 is a medium-severity (CVSS 5.3) CWE-190 vulnerability in soroban-sdk. A fix is available for soroban-sdk — see the affected versions and patch details below.
soroban-sdk has overflow in Bytes::slice, Vec::slice, GenRange::gen_range for u64
Exploitation Status
No confirmed exploitation observed yet
- CISA assesses this as automatable — exploitation doesn’t require manual, per-target effort, which raises the odds of mass scanning and opportunistic attacks.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for CVE-2026-24889.
EPSS Exploitation Probability
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.
How urgent is this, really
CVE-2026-24889 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.
Where this sits among everything scored
Of 377,636 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.
Real-World Exposure
soroban-sdk🦀soroban-sdk🦀soroban-sdkReal-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)— endu32::MAX + 1wraps to0, producingslice(0..0)returning empty instead of the full range.Bytes::slice((Bound::Excluded(u32::MAX), Bound::Unbounded))— startu32::MAX + 1wraps to0, producingslice(0..)instead of an empty/invalid range.
Vec::slice:
Vec::slice(0..=u32::MAX)— same asBytes, end wraps to0, returning empty.Vec::slice((Bound::Excluded(u32::MAX), Bound::Unbounded))— same asBytes, start wraps to0.
Prng::gen_range:
Prng::gen_range((Bound::Unbounded, Bound::Excluded(0)))— end0 - 1wraps tou64::MAX, producing range0..=u64::MAXinstead of an empty/invalid range.Prng::gen_range((Bound::Excluded(u64::MAX), Bound::Unbounded))— startu64::MAX + 1wraps to0, producing range0..=u64::MAXinstead 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 startu32::MAX + 1and endu32::MAX + 1wrap to0, producingslice(0..0).Vec::slice(u32::MAX..=u32::MAX)— same asBytes, both wrap to0.
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)orBound::Included(u32::MAX)toBytes::sliceorVec::slice. - Do not pass
Bound::Excluded(u64::MAX)as a start bound orBound::Excluded(0)as an end bound toPrng::gen_range::<u64>.
References
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | soroban-sdk | ≥ 25.0.0&&< 25.0.2 | 25.0.2cargo update -p soroban-sdk --precise 25.0.2 |
| 🦀crates.io | soroban-sdk | ≥ 23.0.0&&< 23.5.1 | 23.5.1cargo update -p soroban-sdk --precise 23.5.1 |
| 🦀crates.io | soroban-sdk | all versions | 22.0.9cargo update -p soroban-sdk --precise 22.0.9 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for soroban-sdk, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update soroban-sdk to 25.0.2 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-24889 is resolved across your whole dependency graph.
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.
How O3 protects you
O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-24889 can be triaged on real exposure rather than presence alone.
Tailored to CVE-2026-24889. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is CVE-2026-24889 in your dependencies?
O3 Security finds CVE-2026-24889 across crates.io dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.