CVE-2026-56744

@bsv/wallet-toolbox provides BRC-100 wallet signing and storage components, while @bsv/wallet-toolbox-client and @bsv/wallet-toolbox-mobile provide client-focused distributions for standard and mobile applications using wallet storage services. A vulnerability in these packages causes transactions created through a remote StorageClient to trust output locking scripts returned by the storage provider without verifying that they match the outputs requested by the caller. A malicious or compromised storage provider can substitute a recipient script or inject an additional output, causing the wallet to sign and broadcast a transaction that redirects funds while the application and user interface continue to display the intended recipient. Source and npm publication history indicate that stable versions @bsv/wallet-toolbox and @bsv/wallet-toolbox-client from 1.1.47 through 2.3.3, and @bsv/wallet-toolbox-mobile from its initial 1.3.21 release through 2.3.3, are affected. All three packages are patched in version 2.4.0. Applications unable to upgrade should avoid remote StorageClient providers, use local storage, or independently verify every transaction output’s locking script and value against the original request before signing

@bsv/wallet-toolbox provides BRC-100 wallet signing and storage components, while @bsv/wallet-toolbox-client and @bsv/wallet-toolbox-mobile provide client-focused distributions for standard and mobile applications using wallet storage services. A vulnerability in these packages causes transactions created through a remote StorageClient to trust output locking scripts returned by the storage provider without verifying that they match the outputs requested by the caller. A malicious or compromised storage provider can substitute a recipient script or inject an additional output, causing the wallet to sign and broadcast a transaction that redirects funds while the application and user interface continue to display the intended recipient. Source and npm publication history indicate that stable versions @bsv/wallet-toolbox and @bsv/wallet-toolbox-client from 1.1.47 through 2.3.3, and @bsv/wallet-toolbox-mobile from its initial 1.3.21 release through 2.3.3, are affected. All three packages are patched in version 2.4.0. Applications unable to upgrade should avoid remote StorageClient providers, use local storage, or independently verify every transaction output’s locking script and value against the original request before signing

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.

@bsv/wallet-toolbox provides BRC-100 wallet signing and storage components, while @bsv/wallet-toolbox-client and @bsv/wallet-toolbox-mobile provide client-focused distributions for standard and mobile applications using wallet storage services. A vulnerability in these packages causes transactions created through a remote StorageClient to trust output locking scripts returned by the storage provider without verifying that they match the outputs requested by the caller. A malicious or compromised storage provider can substitute a recipient script or inject an additional output, causing the wallet to sign and broadcast a transaction that redirects funds while the application and user interface continue to display the intended recipient. Source and npm publication history indicate that stable versions @bsv/wallet-toolbox and @bsv/wallet-toolbox-client from 1.1.47 through 2.3.3, and @bsv/wallet-toolbox-mobile from its initial 1.3.21 release through 2.3.3, are affected. All three packages are patched in version 2.4.0. Applications unable to upgrade should avoid remote StorageClient providers, use local storage, or independently verify every transaction output’s locking script and value against the original request before signing

@bsv/wallet-toolbox provides BRC-100 wallet signing and storage components, while @bsv/wallet-toolbox-client and @bsv/wallet-toolbox-mobile provide client-focused distributions for standard and mobile applications using wallet storage services. A vulnerability in these packages causes transactions created through a remote StorageClient to trust output locking scripts returned by the storage provider without verifying that they match the outputs requested by the caller. A malicious or compromised storage provider can substitute a recipient script or inject an additional output, causing the wallet to sign and broadcast a transaction that redirects funds while the application and user interface continue to display the intended recipient. Source and npm publication history indicate that stable versions @bsv/wallet-toolbox and @bsv/wallet-toolbox-client from 1.1.47 through 2.3.3, and @bsv/wallet-toolbox-mobile from its initial 1.3.21 release through 2.3.3, are affected. All three packages are patched in version 2.4.0. Applications unable to upgrade should avoid remote StorageClient providers, use local storage, or independently verify every transaction output’s locking script and value against the original request before signing

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.