Top 10 Ways Soroban Contracts Get Hacked
Soroban is the smart contract platform built on the Stellar network and follows a design that is intentionally different from EVM-based systems. Contracts execute deterministically with explicit authorization, integer-only arithmetic, and a resource-metered storage model. There are no implicit permissions: every sensitive action must call require_auth, and failing to do so results in critical access control vulnerabilities. Arithmetic operations do not support floating-point math, making precision handling and operation ordering a common source of bugs.
Storage in Soroban is a key–value store with rent and TTL, where entries can expire unless explicitly extended, and every write increases long-term execution cost. Developers must choose between persistent and temporary storage and enforce strict bounds, as unbounded or user-controlled writes can permanently bloat state or cause denial of service. Additionally, Soroban transactions are publicly observable before ledger close and executed in ordered ledgers, which introduces front-running risks when contract logic depends on mutable on-chain state without user-defined limits.
These architectural choices improve safety and predictability at the protocol level, but they also introduce ecosystem-specific attack patterns when developers apply assumptions from other smart contract platforms. The vulnerabilities outlined below reflect the most common ways these design constraints are misunderstood or misused in real Soroban contracts.
Note: It's expected that you have prior background in EVM Security or Rust security in general to understsand the issues.
1. Access Control Issue:
Failing to validate that the caller has the necessary permissions is one of the most common vulnerabilities in not only in smart contracts also in any other environment.
Check out this example, and think what’s wrong?
So basically the problem with this is - it checks require_auth() for the admin parameter passed in set_admin function by any user. So the attacker could pass valid admin address, and it will be validated from the user input instead of the user's actual address.
Remediation:
Fetch the current_admin directly from storage instead of relying on user controlled parameters.
2. Precision loss
Performing a division operation before a multiplication can lead to a loss of precision, as division between integers might return zero.
Example of a vulnerable vault:
Basically, Soroban doesn’t support floating points hence the ones from solidity background already know this bug. This is an classical precision loss issue. Let’s understand it with example:
assets = 1000 , total_assets = 10,000, total shares = 100
So with this configuration, the calculation would result in:
assets / total_assets * total_shares
= 1000 / 10000 * 100
= 0 * 100 (as to how fixed point math works)
= 0
Expected = 10
Actual = 0
Remediation:
Always perform multiplication before division
3. Insufficient Input Validation
Accepting user input without proper validation can lead to unexpected contract behavior or exploitation. Look for missing bounds checks on numeric inputs, unchecked string lengths, unvalidated addresses, or accepting negative values where only positive makes sense.
Have a look at this example:
Remediation:
Validate the user input with the apt bounds.
4. Front running
Front-running isn’t just an EVM problem. Soroban runs on the Stellar network, where transactions are publicly visible before ledger close. Even though it’s not called a “mempool,” pending Soroban transactions can be observed and reordered before execution — which is functionally equivalent to a public mempool.
Check out the classic example of a vulnerable function in a Soroban Uniswap-like contract:
Alice submits a large swap. An attacker sees it pending and swaps first, shifting reserves. Alice’s transaction executes after reserves change and hence she receives far fewer tokens than expected.
Remediation:
Add slippage protection by adding min_amount parameter.
5. Weak random value generation
Soroban does not provide secure on-chain randomness. Using ledger data or block attributes like timestamp, sequencer as “random” on the Stellar network is predictable and exploitable.
Consider the following example to roll for lottery:
The issue with the code is that attackers can predict outcomes, delay or reorder tx, and also submit when result is favorable.
Remediation:
Consider using PRNG for random number generation.
6. Unprotected update_current_contract_wasm
Upgrading a smart contract allows you to improve or modify your contract without changing its address. And update_current_contract_wasm() function is called without a previous check of the address of the caller. Hence, they can intentionally modify the contract behaviour, leading to the loss of all associated data/tokens and functionalities given by this contract or by others dependency contracts.
Here’s an example pattern of using the inprotected function :
Remediation:
Add access control protection, as in here only the admin can upgrade. Also, it checks if the admin address is initialized.
7. Storage issues
In Soroban on the Stellar network, storage is a key–value store with rent and TTL, not free or implicitly permanent. Every write costs resources, and data can expire unless its TTL is explicitly extended. Contracts choose between persistent storage (long-lived, more expensive) and temporary storage (short-lived, auto-expiring). Because keys and values are fully controlled by contract code, mistakes like unbounded writes, user-supplied keys, or missing init guards can permanently bloat state, overwrite critical values, or make future calls fail. In practice, storage needs bounds, namespacing, access control, and explicit TTL management.
Below is a single Soroban-style contract that intentionally demonstrates the most common storage bugs developers ship on the Stellar network:
Remediation:
Check the comments to understand the guards in place.
8. Outdated Soroban Version
Using an outdated version of Soroban can lead to various security issues in the contract.
Remediation:
Monitor and keep the soroban-sdk version and also other dependencies to the latest version.
9. Unprotected Mapping Operations
A very common Soroban bug on the Stellar network is writing to mappings (storage maps) without access control or bounds. If users can freely write or overwrite mapping entries, they can corrupt state, overwrite critical data, or grow storage indefinitely.
Vulnerable pattern for mapping operation:
Remediation:
Always authorize the user before making any change via mapping to storage to ensure others cannot perform the malicious action.
10. Unrestricted Transfer From
A critical and common bug in Soroban contracts on the Stellar network is allowing transfers from an arbitrary address without authorization. Unlike some assumptions devs bring from other ecosystems, Soroban does not implicitly authenticate the caller or the from address.
Yes, you are correct—anyone can drain funds from from address.
Remediation:
Authorize the source account with require_auth()
