https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Mon, 05 Oct 2026 06:18:56 +0000 https://vulnerability.circl.lu/vuln/fkie_cve-2026-56744 <p>`@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</p> <p>`@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</p> https://vulnerability.circl.lu/vuln/fkie_cve-2026-56744 https://vulnerability.circl.lu/vuln/ghsa-36f9-7rg5-cpf8 <p><strong>Affected:</strong> npm: @bsv/wallet-toolbox, npm: @bsv/wallet-toolbox-client, npm: @bsv/wallet-toolbox-mobile</p> <p>Reported by @echennells (Eric Chennells). Migrated from public issue #191 to a private advisory.</p> <p>**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</p> <p>**Summary:** When `createAction` runs against a remote `StorageClient`, the storage server returns the outputs to build. `buildSignableTransaction` takes each non-change output&#39;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.</p> <p>**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.</p> <p>**Context:** Remote storage is a s…</p> <p><strong>Affected:</strong> npm: @bsv/wallet-toolbox, npm: @bsv/wallet-toolbox-client, npm: @bsv/wallet-toolbox-mobile</p> <p>Reported by @echennells (Eric Chennells). Migrated from public issue #191 to a private advisory.</p> <p>**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</p> <p>**Summary:** When `createAction` runs against a remote `StorageClient`, the storage server returns the outputs to build. `buildSignableTransaction` takes each non-change output&#39;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.</p> <p>**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.</p> <p>**Context:** Remote storage is a s…</p> https://vulnerability.circl.lu/vuln/ghsa-36f9-7rg5-cpf8