GHSA-36f9-7rg5-cpf8 `@bsv/wallet-toolbox` / `-client` / `-mobile` don't verify storage-supplied recipient output scripts against caller-requested outputs in createAction

• npm @bsv/wallet-toolbox: >= 1.1.47, < 2.4.0 → fixed in 2.4.0 • npm @bsv/wallet-toolbox-client: >= 1.1.47, < 2.4.0 → fixed in 2.4.0 • npm @bsv/wallet-toolbox-mobile: >= 1.3.21, < 2.4.0 → fixed in 2.4.0

Reported by @echennells (Eric Chennells). Migrated from public issue #191 to a private advisory. Affected: `@bsv/wallet-toolbox` / `-client` / `-mobile`. Verified in `2.1.21` and `2.1.21-parity-fix.2`; the relevant code is the same at current HEAD Summary: When `createAction` runs against a remote `StorageClient`, the storage server returns the outputs to build. `buildSignableTransaction` takes each non-change output's `lockingScript` from the storage response and signs it, without comparing it to the `lockingScript` the caller supplied in `args.outputs`. `WalletPermissionsManager.createAction` parses the built transaction and has `args.outputs` available, but uses the tx only for `inputs` and `getFee()`; it does not inspect `tx.outputs`. A storage provider that returns a different recipient script than requested will therefore have that script signed and broadcast, while the calling app and UI still show the originally requested recipient. Relevant code: • `signer/methods/buildSignableTransaction.js` — non-change output `lockingScript = asBsvSdkScript(out.lockingScript)`, sourced from the storage response; `args.outputs` is not consulted. • `WalletPermissionsManager.js` `createAction` — parses the built tx, derives spend from `args.outputs` satoshis + `tx.getFee()`, reads `tx.inputs`; does not read `tx.outputs`. • `signer/methods/signAction.js`, `completeSignedTransaction.js` — sign the as-built tx; no output comparison. Context: Remote storage is a supported, default configuration (`StorageClient` over BRC-103 `AuthFetch`, default endpoint `storage.babbage.systems`, optional payment middleware). The mutual auth establishes the storage server's identity and protects the channel, but the contents it returns are not validated against the request. The attacker is the storage operator, or anyone who compromises it — not a passive network MITM. (`StorageServer.processAction` does compare the signed rawTx outputs to what storage stored, so a response-only MITM is rejected; an operator stores the substituted script from the start.) Proof of concept: We ran a storage server that returns a substituted recipient output, and pointed a current yours-wallet build at it as its active storage provider. With the wallet otherwise unmodified, a payment requested to one address was built, signed, and broadcast paying a different address, the substitution was not surfaced anywhere in the wallet.