What is GHSA-PM4J-7R4Q-CCG8?

GHSA-PM4J-7R4Q-CCG8 is a low-severity security vulnerability in soroban-env-host (rust), affecting versions < 26.0.0. It is fixed in 26.0.0.

Which versions of soroban-env-host are affected by GHSA-PM4J-7R4Q-CCG8?

soroban-env-host (rust) versions < 26.0.0 is affected.

Is there a fix for GHSA-PM4J-7R4Q-CCG8?

Yes. GHSA-PM4J-7R4Q-CCG8 is fixed in 26.0.0. Upgrade to this version or later.

Is GHSA-PM4J-7R4Q-CCG8 exploitable, and should I be worried?

Whether GHSA-PM4J-7R4Q-CCG8 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk.

What actually determines whether GHSA-PM4J-7R4Q-CCG8 is exploitable, and how bad it is?

Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.

How do I fix GHSA-PM4J-7R4Q-CCG8?

Upgrade soroban-env-host to 26.0.0 or later.

GHSA-PM4J-7R4Q-CCG8 in soroban-env-host

Q: Which versions of soroban-env-host are affected by GHSA-PM4J-7R4Q-CCG8?

soroban-env-host (rust) versions < 26.0.0 is affected.

Q: Is there a fix for GHSA-PM4J-7R4Q-CCG8?

Yes. GHSA-PM4J-7R4Q-CCG8 is fixed in 26.0.0. Upgrade to this version or later.

Q: Is GHSA-PM4J-7R4Q-CCG8 exploitable, and should I be worried?

Whether GHSA-PM4J-7R4Q-CCG8 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk.

Q: What actually determines whether GHSA-PM4J-7R4Q-CCG8 is exploitable, and how bad it is?

Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.

Q: How do I fix GHSA-PM4J-7R4Q-CCG8?

Upgrade soroban-env-host to 26.0.0 or later.

Summary

Soroban: Muxed address<->ScVal conversions may break after a conversion failure

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.

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.

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.

Affected versions

soroban-env-host (< 26.0.0)

Security releases

soroban-env-host → 26.0.0 (rust)

Kodem intelligence

Severity tells you how bad this could be in the worst case. It does not tell you whether you are exposed. Exploitability and impact are functions of runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A vulnerable package can sit in your dependency tree and never run.

Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter. Kodem's runtime-powered SCA identifies whether this CVE is reachable in your applications.

Already deployed Kodem?

See it in your environment New to Kodem? Get a demo →

Remediation advice

The bug will be fixed in protocol 26.

Frequently Asked Questions

What is GHSA-PM4J-7R4Q-CCG8? GHSA-PM4J-7R4Q-CCG8 is a low-severity security vulnerability in soroban-env-host (rust), affecting versions < 26.0.0. It is fixed in 26.0.0.
Which versions of soroban-env-host are affected by GHSA-PM4J-7R4Q-CCG8? soroban-env-host (rust) versions < 26.0.0 is affected.
Is there a fix for GHSA-PM4J-7R4Q-CCG8? Yes. GHSA-PM4J-7R4Q-CCG8 is fixed in 26.0.0. Upgrade to this version or later.
Is GHSA-PM4J-7R4Q-CCG8 exploitable, and should I be worried? Whether GHSA-PM4J-7R4Q-CCG8 is exploitable in your environment depends on whether the vulnerable code is present and reachable. A CVSS score is a worst-case rating; it does not account for your specific deployment, configuration, or usage patterns. Kodem, an Intelligent Application Security platform, uses runtime intelligence to show which vulnerabilities actually execute in production, so you can focus on the ones that represent real risk. Get a demo
What actually determines whether GHSA-PM4J-7R4Q-CCG8 is exploitable, and how bad it is? Exploitability and impact are not fixed properties of a CVE. They depend on runtime truth: whether the vulnerable code is present, reachable, and actually executes in your application. A high CVSS score on a dependency that never runs is not the same as real risk. Kodem, an Intelligent Application Security platform, uses runtime intelligence to reveal which vulnerabilities actually execute in production, so teams prioritize the ones that genuinely matter.
How do I fix GHSA-PM4J-7R4Q-CCG8? Upgrade soroban-env-host to 26.0.0 or later.