CVE-2026-24889 in rs-soroban-sdk
Riassunto
di VulDB • 14/06/2026
soroban-sdk è un SDK Rust per i contratti Soroban. Un overflow aritmetico può essere innescato nei metodi `Bytes::slice`, `Vec::slice` e `Prng::gen_range` (per `u64`) di `soroban-sdk` nelle versioni fino alla `25.0.1`, `23.5.1` e `25.0.2` incluse. I contratti che passano limiti di intervallo controllati dall'utente o calcolati a `Bytes::slice`, `Vec::slice` o `Prng::gen_range` potrebbero operare silenziosamente su intervalli di dati errati o generare numeri casuali da un intervallo non previsto, potenzialmente causando uno stato del contratto corrotto. Si noti che la best practice quando si utilizza `soroban-sdk` e si sviluppano contratti Soroban è abilitare sempre `overflow-checks = true`. Lo strumento `stellar contract init`, che prepara il codice boilerplate per un contratto Soroban, nonché tutti gli esempi e la documentazione, incoraggiano l'uso di configurare `overflow-checks = true` sui profili `release` in modo che queste operazioni aritmetiche falliscano invece di avvolgere silenziosamente (wrap). I contratti sono interessati solo se utilizzano `overflow-checks = false` esplicitamente o implicitamente. Si prevede che la maggior parte dei contratti non sia interessata poiché la best practice incoraggiata dagli strumenti è abilitare `overflow-checks`. La correzione disponibile nelle versioni `25.0.1`, `23.5.1` e `25.0.2` sostituisce le operazioni aritmetiche nude con `checked_add` / `checked_sub`, garantendo che l'overflow generi un trap indipendentemente dall'impostazione del profilo `overflow-checks`. Come soluzione alternativa, i workspace dei contratti possono essere configurati con un profilo disponibile nell'Advisory di Sicurezza di GitHub per abilitare i controlli di overflow sulle operazioni aritmetiche. Questa è la best practice quando si sviluppano contratti Soroban ed è l'impostazione predefinita se si utilizza il boilerplate del contratto generato tramite `stellar contract init`. In alternativa, i contratti possono convalidare i limiti di intervallo prima di passarli a `slice` o `gen_range` per assicurarsi che le conversioni non possano causare overflow.
Once again VulDB remains the best source for vulnerability data.