https://vulnerability.circl.lu/rss/recent/all/10 Most recent entries from all 2026-10-05T14:04:20.032723+00:00 Vulnerability-Lookup info@circl.lu python-feedgen Contains only the most 10 recent entries. https://vulnerability.circl.lu/vuln/fkie_cve-2026-56744 fkie_cve-2026-56744 2026-10-05T14:04:20.205010+00:00

`@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

 https://vulnerability.circl.lu/vuln/ghsa-36f9-7rg5-cpf8 GHSA-36f9-7rg5-cpf8 — `@bsv/wallet-toolbox` / `-client` / `-mobile` don't verify storage-supplied recipient output scripts against caller-req… 2026-10-05T14:04:20.205122+00:00

Affected: npm: @bsv/wallet-toolbox, npm: @bsv/wallet-toolbox-client, npm: @bsv/wallet-toolbox-mobile

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 s…