GHSA-96XM-FV9W-PF3F
Vulnerability from github – Published: 2026-01-28 22:20 – Updated: 2026-01-29 03:56Impact
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)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
- https://github.com/stellar/rs-soroban-sdk/pull/1703
- https://github.com/stellar/rs-soroban-sdk/releases/tag/v25.0.2
- https://github.com/stellar/rs-soroban-sdk/releases/tag/v23.5.1
- https://github.com/stellar/rs-soroban-sdk/releases/tag/v22.0.9
{
"affected": [
{
"package": {
"ecosystem": "crates.io",
"name": "soroban-sdk"
},
"ranges": [
{
"events": [
{
"introduced": "25.0.0"
},
{
"fixed": "25.0.2"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "soroban-sdk"
},
"ranges": [
{
"events": [
{
"introduced": "23.0.0"
},
{
"fixed": "23.5.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "crates.io",
"name": "soroban-sdk"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "22.0.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-24889"
],
"database_specific": {
"cwe_ids": [
"CWE-190"
],
"github_reviewed": true,
"github_reviewed_at": "2026-01-28T22:20:35Z",
"nvd_published_at": "2026-01-28T22:15:56Z",
"severity": "MODERATE"
},
"details": "### Impact\n\nArithmetic 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`.\n\nContracts 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.\n\nNote 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`.\n\n### Detail\n\nWhen 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\u0027s intent:\n\n`Bytes::slice`:\n- `Bytes::slice(0..=u32::MAX)` \u2014 end `u32::MAX + 1` wraps to `0`, producing `slice(0..0)` returning empty instead of the full range.\n- `Bytes::slice((Bound::Excluded(u32::MAX), Bound::Unbounded))` \u2014 start `u32::MAX + 1` wraps to `0`, producing `slice(0..)` instead of an empty/invalid range.\n\n`Vec::slice`:\n- `Vec::slice(0..=u32::MAX)` \u2014 same as `Bytes`, end wraps to `0`, returning empty.\n- `Vec::slice((Bound::Excluded(u32::MAX), Bound::Unbounded))` \u2014 same as `Bytes`, start wraps to `0`.\n\n`Prng::gen_range`:\n- `Prng::gen_range((Bound::Unbounded, Bound::Excluded(0)))` \u2014 end `0 - 1` wraps to `u64::MAX`, producing range `0..=u64::MAX` instead of an empty/invalid range.\n- `Prng::gen_range((Bound::Excluded(u64::MAX), Bound::Unbounded))` \u2014 start `u64::MAX + 1` wraps to `0`, producing range `0..=u64::MAX` instead of an empty/invalid range.\n\nNote 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:\n- `Bytes::slice(u32::MAX..=u32::MAX)` \u2014 both start `u32::MAX + 1` and end `u32::MAX + 1` wrap to `0`, producing `slice(0..0)`.\n- `Vec::slice(u32::MAX..=u32::MAX)` \u2014 same as `Bytes`, both wrap to `0`.\n\n\n### Patches\n\nThe fix replaces bare arithmetic with `checked_add` / `checked_sub`, ensuring overflow traps regardless of the `overflow-checks` profile setting.\n\n### Workarounds\n\nContract 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`:\n\n```toml\n[profile.release]\noverflow-checks = true\n```\n\nAlternatively, contracts can validate range bounds before passing them to `slice` or `gen_range` to ensure the conversions cannot overflow:\n\n- Do not pass `Bound::Excluded(u32::MAX)` or `Bound::Included(u32::MAX)` to `Bytes::slice` or `Vec::slice`.\n- Do not pass `Bound::Excluded(u64::MAX)` as a start bound or `Bound::Excluded(0)` as an end bound to `Prng::gen_range::\u003cu64\u003e`.\n\n### References\n\n- https://github.com/stellar/rs-soroban-sdk/pull/1703\n- https://github.com/stellar/rs-soroban-sdk/releases/tag/v25.0.2\n- https://github.com/stellar/rs-soroban-sdk/releases/tag/v23.5.1\n- https://github.com/stellar/rs-soroban-sdk/releases/tag/v22.0.9",
"id": "GHSA-96xm-fv9w-pf3f",
"modified": "2026-01-29T03:56:38Z",
"published": "2026-01-28T22:20:35Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/stellar/rs-soroban-sdk/security/advisories/GHSA-96xm-fv9w-pf3f"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24889"
},
{
"type": "WEB",
"url": "https://github.com/stellar/rs-soroban-sdk/pull/1703"
},
{
"type": "WEB",
"url": "https://github.com/stellar/rs-soroban-sdk/commit/3890521426d71bb4d892b21f5a283a1e836cfa38"
},
{
"type": "WEB",
"url": "https://github.com/stellar/rs-soroban-sdk/commit/59fcef437260ed4da42d1efb357137a5c166c02e"
},
{
"type": "WEB",
"url": "https://github.com/stellar/rs-soroban-sdk/commit/c2757c6d774dbb28b34a0b77ffe282e59f0f8462"
},
{
"type": "PACKAGE",
"url": "https://github.com/stellar/rs-soroban-sdk"
},
{
"type": "WEB",
"url": "https://github.com/stellar/rs-soroban-sdk/releases/tag/v22.0.9"
},
{
"type": "WEB",
"url": "https://github.com/stellar/rs-soroban-sdk/releases/tag/v23.5.1"
},
{
"type": "WEB",
"url": "https://github.com/stellar/rs-soroban-sdk/releases/tag/v25.0.2"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "soroban-sdk has overflow in Bytes::slice, Vec::slice, GenRange::gen_range for u64"
}
Sightings
| Author | Source | Type | Date |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.