GHSA-pm4j-7r4q-ccg8
Soroban: Muxed address<->ScVal conversions may break after a conversion failure
Blast Radius
soroban-env-hostReal-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
Summary
Soroban host ensures that MuxedAddress objects can't be used as storage keys in order to proactively prevent the contract logic bugs. However, due to a bug in Soroban host implementation, a failure in Val->ScVal conversion during the storage key computation will have the flag indicating that storage conversion is happening stuck in the true state until the next storage access. While the flag is stuck in true state, any MuxedAddress object conversions to ScVal will fail, i.e. a failure will occur if a MuxedAddress is emitted in the event or is serialized to XDR via a host function.
Impact
The bug may cause unexpected contract failures in the rare edge case scenarios. In the worst case scenario the whole transaction will fail and the changes will be rolled back. Because the contract call is simply rolled back, there is no risk of the state corruption.
An example scenario that would be affected by the bug is as follows:
- Contract A calls contract B via
try_call - Contract B calls a storage function (e.g.
put_contract_data) with a non-convertibleValas a key (e.g. aMuxedAddressobject, or a deeply nested vector) - Contract B fails
- Contract A handles the failure gracefully and proceeds without accessing any storage methods
- Contract A tries to emit an event with a
MuxedAddressargument. That should be allowed, but instead of succeeding, contract A fails.
Patches
The bug will be fixed in protocol 26.
Workarounds
We believe that the bug is highly unlikely to occur in practice, as it involves three rare events happening simultaneously: Val conversion failure (these should normally not occur for the audited protocols), graceful handling of a cross-contract call failure (most protocols need cross-contract calls to succeed, or fail with a contract error), and MuxedAddress write (most of the contracts don't support MuxedAddress at all).
In the case if the bug does occur, the mitigation depends on the reason of the value conversion failure:
- If the conversion failure has been caused by a malicious contract, then either no action is necessary (because the whole interaction is malicious and has been correctly rolled back), or the contract invocation should be replaced by a non-malicious contract
- If the conversion failure has been caused by a bad user input for a non-malicious contract (e.g. a bad user input passed to a legitimate protocol), then the user input has to be fixed
In both scenarios the mitigation is to basically retry the transaction with proper arguments.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | soroban-env-host | all versions | 26.0.0 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for soroban-env-host. 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.
Fix
Update soroban-env-host to 26.0.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-pm4j-7r4q-ccg8 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 pinpoints whether GHSA-pm4j-7r4q-ccg8 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-pm4j-7r4q-ccg8. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-pm4j-7r4q-ccg8 in your dependencies?
O3 detects GHSA-pm4j-7r4q-ccg8 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.