Monitor vulnerabilities like this one.
Sign up free to get alerted when software you use is affected.
7.8
Soroban: Muxed address conversions may fail after error
GHSA-pm4j-7r4q-ccg8
Summary
A bug in Soroban's conversion process can cause unexpected contract failures if a specific sequence of events occurs. This is a rare scenario, but it may happen if a contract tries to use a non-convertible value as a key in a storage function and then tries to emit an event with a MuxedAddress argument. The issue will be fixed in a future Soroban update, but in the meantime, there are no known workarounds.
What to do
- Update soroban-env-host to version 26.0.0.
Affected software
| Vendor | Product | Affected versions | Fix available |
|---|---|---|---|
| – | soroban-env-host | <= 26.0.0 | 26.0.0 |
Original title
Soroban: Muxed address<->ScVal conversions may break after a conversion failure
Original 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-convertible `Val` as a key (e.g. a `MuxedAddress` object, 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 `MuxedAddress` argument. 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.
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-convertible `Val` as a key (e.g. a `MuxedAddress` object, 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 `MuxedAddress` argument. 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.
osv CVSS4.0
7.8
Vulnerability type
CWE-681
Published: 7 Mar 2026 · Updated: 13 Mar 2026 · First seen: 7 Mar 2026