EUVD-2026-86301Published

`@bsv/wallet-toolbox` / `-client` / `-mobile` don't verify storage-supplied recipient output scripts against caller-requested outputs in createAction (can redirect payments when using remote storage)

Collected exploitation and prediction evidence

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

cve-program · CVE-2026-56744

Published

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

Source published: 24 Sep 2026 16:56:12 UTC
Source modified: 28 Sep 2026 17:17:16 UTC
Observed here: 23 Oct 2026 15:48:27 UTC
Source terms: CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 4.0 · 8.7 CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

euvd · EUVD-2026-86301

Published

EUVD source date text has no stated timezone and is retained without inventing a UTC instant. Related bulletin membership is not an alias, common cause or applicability claim. A missing vector with a zero score is treated as unrated. Complete vendor/product and underlying source evidence remains in the original JSON.

Original publisher date fields

datePublished: Sep 24, 2026, 4:56:12 PM

dateUpdated: Sep 28, 2026, 5:17:16 PM

Source published: Sep 24, 2026, 4:56:12 PM (timezone not stated)
Source modified: Sep 28, 2026, 5:17:16 PM (timezone not stated)
Observed here: 11 Nov 2026 14:07:06 UTC
Source terms: ENISA EUVD · source terms and attribution apply

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: euvd · ENISA EUVD · source terms and attribution apply. Source text is retained; field grouping and change labels are provided by ChangeIntel.

EUVD CVSS 4.0 · 8.7 CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

nvd · CVE-2026-56744

Published

NVD analysis and CPE criteria are source context, not proof that a package or your environment is affected. Complete affected data, logical configurations and SSVC are retained in the original JSON.

Source analysis status: Deferred

Weakness classifications: CWE-1288

Original publisher date fields

published: 2026-09-24T17:17:05.047

lastModified: 2026-09-30T19:57:08.043

Source published: 24 Sep 2026 17:17:05 UTC
Source modified: 30 Sep 2026 19:57:08 UTC
Observed here: 25 Oct 2026 14:19:10 UTC
Source terms: NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 4.0 · [email protected] · Secondary · 8.7 CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X

osv · GHSA-36f9-7rg5-cpf8

Published

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.

Source published: 24 Sep 2026 19:32:00 UTC
Source modified: 24 Sep 2026 19:45:04 UTC
Observed here: 24 Oct 2026 13:17:17 UTC
Source terms: GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V4 · CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N

Publisher rating · HIGH