GHSA-PM4J-7R4Q-CCG8: State Inconsistency in Soroban Host Storage Key Conversion

The Soroban host environment acts as the runtime for smart contracts on the Stellar network, managing memory, execution, and storage access. To maintain ledger consistency and prevent specific classes of bugs, the host enforces strict type policies for data stored in the ledger. One such policy prohibits the use of MuxedAddress objects as keys in contract storage. This enforcement relies on an internal state tracking mechanism: before converting a Val (runtime value) to an ScVal (storage value) for use as a key, the host sets a context flag indicating a conversion is active.

GHSA-PM4J-7R4Q-CCG8 identifies a defect in this state management logic. The vulnerability manifests when a conversion attempt fails—whether due to malicious input, resource limits, or invalid types. In affected versions of soroban-env-host (prior to 26.0.0), the cleanup logic fails to reset the 'conversion in progress' flag upon encountering an error. This leaves the host in a corrupted state where it believes it is perpetually processing a storage key.

The immediate consequence is that subsequent legitimate operations within the same transaction are subjected to the strict storage key constraints inappropriately. If a contract attempts to emit an event or serialize data containing a MuxedAddress after the flag is stuck, the host rejects the operation, causing the transaction to fail. While this does not corrupt ledger data, it creates a denial-of-service vector for complex contract interactions.

The root cause lies in the error handling path of the Val to ScVal conversion routine within the host's storage subsystem. The host employs a flag—conceptually in_storage_key_conversion—to contextually alter the behavior of type conversion functions. When this flag is true, the converter strictly rejects MuxedAddress types, which are not permitted in storage keys but are allowed elsewhere (e.g., in events or return values).

In a correct implementation, this flag would be managed using a Resource Acquisition Is Initialization (RAII) pattern or a try/finally block to ensure it is reset regardless of the operation's outcome. However, in the vulnerable code, the reset logic is bypassed when an error occurs during the conversion process. If the conversion function returns early due to an error (such as a depth limit violation or an invalid type encounter), the instruction to toggle the flag back to false is never executed.

This results in a 'stuck' state. The host object persists across calls within a single transaction. Therefore, if a nested contract call triggers this failure and returns an error, the parent contract—if it handles the error gracefully—continues executing with the poisoned host state. Any subsequent call by the parent that triggers a check against in_storage_key_conversion will behave as if it is inside a storage key conversion, leading to false positives in the validation logic.

Exploiting this vulnerability requires a specific transaction structure involving nested smart contract calls and error handling. The attacker does not need special privileges but must craft a transaction that induces a failure in a child call while keeping the parent execution alive. The goal is to trigger the bug in the child context and observe the side effect in the parent context.

Attack Sequence

1. Orchestration: A malicious or compromised Contract A initiates a call to Contract B using a safe invocation method (e.g., try_call).
2. Trigger: Contract B attempts to write to storage using a MuxedAddress as the key. The host sets in_storage_key_conversion = true and attempts the conversion.
3. State Corruption: The conversion fails because MuxedAddress is prohibited. The host returns an error to Contract B, but due to the bug, in_storage_key_conversion remains true.
4. Propagation: Contract B fails. Contract A catches the error (via try_call) and proceeds with its execution flow.
5. Denial of Service: Contract A attempts a valid operation, such as emitting an event that includes a MuxedAddress. The host checks the stuck flag, incorrectly determines this is a storage key conversion, and rejects the valid event emission. The entire transaction rolls back.

This mechanism effectively allows a sub-call to sabotage the execution of the calling contract, even if the caller correctly handles the sub-call's failure. This violates the isolation guarantees expected between contract invocations.

The severity of this vulnerability is classified as Low (CVSS 1.7), primarily because it affects availability rather than confidentiality or integrity. There is no risk of data theft, arbitrary code execution, or permanent ledger corruption. The impact is limited to the runtime execution of specific transactions.

Availability Impact: The primary consequence is the failure of legitimate transactions. In complex DeFi protocols where contracts interact dynamically, a single failing sub-component could inadvertently trigger this state bug, causing the main protocol logic to fail unexpectedly. This could be used for griefing attacks, where an attacker intentionally triggers the bug to prevent a specific contract path from executing.

Integrity Impact: There is no direct integrity loss. The ledger state remains consistent because the transaction affecting the state is rolled back. The "corruption" is transient and confined to the volatile memory of the host during the transaction's lifecycle. Once the transaction concludes (fails), the host instance is discarded, and the state is reset for the next transaction.

The vulnerability is addressed in soroban-env-host version 26.0.0, which introduces Protocol 26 changes. The fix involves ensuring that the state tracking flag is robustly reset even in the event of a conversion failure. This is likely achieved by implementing a Drop guard or similar scope-based cleanup mechanism that guarantees the flag's restoration upon scope exit.

Mitigation Strategies

Since this is a logic bug within the blockchain's execution environment, individual smart contract developers cannot "patch" the host. However, they can employ defensive coding practices to minimize impact until the network upgrades:

1. Input Validation: Rigorously validate all inputs before attempting storage operations. Preventing the invalid conversion call (e.g., checking if a key is a MuxedAddress before using it) avoids triggering the host bug.
2. Avoid MuxedAddress in Keys: Adhere strictly to best practices by avoiding complex or prohibited types in storage keys.
3. Monitor Failures: Watch for unexpected HostError or transaction failures involving event emission, which may indicate this specific edge case is being triggered.