CVE-2026-56744: 
JavaScript vulnerability analysis and mitigation

CVE-2026-56744 is a transaction output tampering vulnerability in the BSV blockchain wallet toolbox npm packages (@bsv/wallet-toolbox, @bsv/wallet-toolbox-client, and @bsv/wallet-toolbox-mobile) that allows a malicious or compromised remote storage provider to redirect cryptocurrency payments without the user's knowledge. The flaw was reported by Eric Chennells and disclosed on September 24, 2026. Affected versions are @bsv/wallet-toolbox and @bsv/wallet-toolbox-client from 1.1.47 through 2.3.3, and @bsv/wallet-toolbox-mobile from 1.3.21 through 2.3.3. It carries a CVSS v4.0 base score of 8.7 (High) (GitHub Advisory).

The root cause is improper validation of consistency within input (CWE-1288): the buildSignableTransaction function in signer/methods/buildSignableTransaction.js takes each non-change output's lockingScript directly from the StorageCreateActionResult response without comparing it to the lockingScript supplied by the caller in args.outputs. Additionally, WalletPermissionsManager.createAction parses the built transaction but only reads inputs and fee data — it never inspects tx.outputs. This means a storage provider operating as a StorageClient (the default remote configuration, e.g., storage.babbage.systems) can substitute a recipient script or inject an additional output funded by reducing change, and the wallet will sign and broadcast the manipulated transaction. The attacker must be the storage operator or someone who has compromised it; a passive network MITM is insufficient because StorageServer.processAction validates the signed raw transaction against what storage stored (GitHub Advisory, Fix Commit).

A malicious or compromised storage provider can silently redirect BSV cryptocurrency funds to an attacker-controlled address while the application's user interface continues to display the originally intended recipient, providing no visible indication of the substitution. The integrity of every transaction created via a remote StorageClient is at risk, with direct financial loss to users. There is no confidentiality or availability impact; the vulnerability is purely an integrity issue affecting transaction outputs (GitHub Advisory).

No public proof-of-concept exploit code has been observed, and there is no evidence of in-the-wild exploitation at the time of disclosure (GitHub Advisory). However, the maintainers confirmed the attack is practical: they ran a modified storage server returning a substituted recipient output and pointed an unmodified yours-wallet build at it, successfully redirecting a payment without any wallet-side indication. The vulnerability requires no privileges or user interaction and is exploitable over the network. The EPSS score is approximately 0.30%, and it is not listed in the CISA KEV catalog (GitHub Advisory).

1. Operate or compromise a StorageClient provider: The attacker must control a BSV storage server (e.g., by operating a custom StorageClient endpoint or compromising an existing one such as storage.babbage.systems). Passive network interception is insufficient.
2. Intercept the createAction call: When a victim wallet application calls createAction with a payment to a legitimate recipient, the storage server receives the request including the caller's intended args.outputs (recipient locking scripts and satoshi amounts).
3. Substitute or inject outputs in the response: The malicious storage server returns a StorageCreateActionResult where either (a) a caller-specified output's lockingScript is replaced with an attacker-controlled script, or (b) an additional output paying the attacker is injected (funded by reducing the change output), while the caller's outputs appear intact.
4. Wallet signs the manipulated transaction: buildSignableTransaction builds the transaction using the storage-supplied scripts without verification. The wallet signs and broadcasts the transaction, sending funds to the attacker's address.
5. UI shows intended recipient: The calling application and user interface continue to display the originally requested recipient, as WalletPermissionsManager.createAction never inspects tx.outputs — the substitution is invisible to the user (GitHub Advisory, Fix Commit).

• Network: Outbound BSV transactions broadcast to the blockchain where the on-chain recipient address differs from the address displayed in the application UI; connections to an unexpected or unauthorized StorageClient endpoint.
• Logs: Application logs showing createAction calls completing successfully while blockchain explorers reveal the transaction outputs do not match the intended recipients; any WERR_INVALID_PARAMETER errors related to output.lockingScript or storage outputs in updated (patched) versions may indicate attempted exploitation.
• Blockchain: On-chain transactions originating from the wallet where output locking scripts do not correspond to the intended recipient addresses as recorded in application-level transaction history.

All three packages are patched in version 2.4.0, which adds verifyRequestedOutputsUnchanged() to hard-fail if storage omits, reclassifies, rescripts, or re-values any caller-specified output, and adds verifyUnrequestedOutputsAreChangeOrCommission() to reject any injected outputs beyond the caller's that are not client-derived change or a single commission output bounded by MAX_STORAGE_COMMISSION_SATOSHIS (500,000 satoshis). Applications unable to upgrade immediately should avoid remote StorageClient providers, use local storage instead, or independently verify every transaction output's locking script and value against the original request before signing (GitHub Advisory, Release Commit).