# GHSA-pm4j-7r4q-ccg8: Soroban: Muxed address<->ScVal conversions may break after a conversion failure

> A bug in Soroban host can cause unexpected transaction failures and rollbacks when specific conversion errors occur, requiring an upgrade to protocol 26.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Not needed
- **Attackable:** Over the internet
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 7 Mar 2026

## What is GHSA-pm4j-7r4q-ccg8?

GHSA-pm4j-7r4q-ccg8 is a denial of service vulnerability in soroban-env-host, published on 7 Mar 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.

### Official 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.

## Which versions are affected by GHSA-pm4j-7r4q-ccg8?

2 open source packages ship an affected version, including soroban-env-host.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `soroban-env-host` | crates.io | All versions | 26.0.0 |
| `soroban-env-host` | crates.io | All versions | 26.0.0 |

## How do I fix GHSA-pm4j-7r4q-ccg8?

Upgrade soroban-env-host to 26.0.0 or later.

## Is GHSA-pm4j-7r4q-ccg8 being exploited?

There is no known exploitation of GHSA-pm4j-7r4q-ccg8 in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-pm4j-7r4q-ccg8 and fix it if it is affected.

What it is: GHSA-pm4j-7r4q-ccg8 is a denial of service vulnerability in soroban-env-host, published on 7 Mar 2026. An attacker can exploit it over the internet without logging in, with no action from the victim.
Exploitation: There is no known exploitation of GHSA-pm4j-7r4q-ccg8 in the wild and no public exploit code.

Affected packages and fixed versions:
- soroban-env-host (crates.io): affected all versions; fixed in 26.0.0
- soroban-env-host (crates.io): affected all versions; fixed in 26.0.0

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-pm4j-7r4q-ccg8/ (Markdown: https://insights.sbomify.com/GHSA-pm4j-7r4q-ccg8/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-pm4j-7r4q-ccg8

---
From sbomify Insights: https://insights.sbomify.com/GHSA-pm4j-7r4q-ccg8/
Summaries are generated and may contain mistakes; the official description above is the record.