Soroban SDK Security Flaw: Malicious RPC Can Reorder Contract Call Arguments via Fetched ABI

A critical security vulnerability has been identified in the Soroban SDK's contract client, where the system implicitly trusts the Application Binary Interface (ABI) fetched from a remote RPC endpoint. The flaw resides in the `Client.from()` and `Client.fromWasmHash()` methods, which retrieve WASM code from a configured RPC and derive the callable contract specification (`Spec`) directly from that remote blob. This dynamic client then uses `spec.funcArgsToScVals(method, args)` to serialize user-provided arguments into the order declared by the fetched spec. Since Soroban's invoke-contract arguments are strictly positional on-chain, and the SDK performs no verification that the fetched WASM or spec matches a locally trusted ABI, a malicious RPC provider holds significant power.

The attack vector is straightforward yet potent. A compromised or malicious RPC endpoint can serve a manipulated WASM blob that maintains the correct parameter names but alters their declared order. When a user's application calls a contract method, the SDK will serialize the arguments according to this maliciously reordered spec. Consequently, the resulting on-chain invocation will have its argument values assigned to incorrect parameters, fundamentally altering the intended logic of the transaction. This manipulation can occur without changing the contract's address or the method name, making it a subtle but severe integrity breach.

This high-severity finding exposes a fundamental trust issue in the client-RPC relationship for Soroban applications. It places the security of contract interactions—and by extension, user funds and application state—on the integrity of the RPC provider. The flaw necessitates immediate scrutiny of the SDK's trust model, as it allows a single point of failure in the data-fetching layer to compromise the semantic correctness of any signed transaction. Developers and auditors must now consider RPC provenance as a critical part of their security posture until the client implements robust ABI verification or local caching mechanisms.