GHSA-36F9-7RG5-CPF8

Vulnerability from github – Published: 2026-09-24 19:32 – Updated: 2026-09-24 19:32
VLAI
Summary
`@bsv/wallet-toolbox` / `-client` / `-mobile` don't verify storage-supplied recipient output scripts against caller-requested outputs in createAction
Details

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.

Severity
8.7 (High)
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
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@bsv/wallet-toolbox"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.1.47"
            },
            {
              "fixed": "2.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@bsv/wallet-toolbox-client"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.1.47"
            },
            {
              "fixed": "2.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "npm",
        "name": "@bsv/wallet-toolbox-mobile"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.3.21"
            },
            {
              "fixed": "2.4.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-56744"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1288"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-24T19:32:00Z",
    "nvd_published_at": "2026-09-24T17:17:05Z",
    "severity": "HIGH"
  },
  "details": "Reported by @echennells (Eric Chennells). Migrated from public issue #191 to a private advisory.\n\n**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\n\n**Summary:**\nWhen `createAction` runs against a remote `StorageClient`, the storage server returns the outputs to build. `buildSignableTransaction` takes each non-change output\u0027s `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.\n\n**Relevant code:**\n - `signer/methods/buildSignableTransaction.js` \u2014 non-change output `lockingScript = asBsvSdkScript(out.lockingScript)`, sourced from the storage response; `args.outputs` is not consulted.\n - `WalletPermissionsManager.js` `createAction` \u2014 parses the built tx, derives spend from `args.outputs` satoshis + `tx.getFee()`, reads `tx.inputs`; does not read `tx.outputs`.\n - `signer/methods/signAction.js`, `completeSignedTransaction.js` \u2014 sign the as-built tx; no output comparison.\n\n**Context:**\nRemote 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\u0027s 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 \u2014 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.)\n\n**Proof of concept:**\nWe 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.",
  "id": "GHSA-36f9-7rg5-cpf8",
  "modified": "2026-09-24T19:32:00Z",
  "published": "2026-09-24T19:32:00Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/bsv-blockchain/ts-stack/security/advisories/GHSA-36f9-7rg5-cpf8"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-56744"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bsv-blockchain/ts-stack/commit/3a11f6111919245a3090e9f3895cfc4f21a80d28"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bsv-blockchain/ts-stack/commit/5492cabbef4ddc7f60cc49cdf5d8c74ed2e5d949"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bsv-blockchain/ts-stack/commit/5ee60395e78e8b822d9a78efeacc6039c249819b"
    },
    {
      "type": "WEB",
      "url": "https://github.com/bsv-blockchain/wallet-toolbox/commit/ca651b067c0238cd8b1ddd3af225daa503857a07"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/bsv-blockchain/ts-stack"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "`@bsv/wallet-toolbox` / `-client` / `-mobile` don\u0027t verify storage-supplied recipient output scripts against caller-requested outputs in createAction"
}



Log in or create an account to share your comment.




Tags
Taxonomy of the tags.





Forecast uses a logistic model when the trend is rising, or an exponential decay model when the trend is falling. Fitted via linearized least squares.

Sightings

Author Source Type Date Other

Nomenclature

  • Seen: The vulnerability was mentioned, discussed, or observed by the user.
  • Confirmed: The vulnerability has been validated from an analyst's perspective.
  • Published Proof of Concept: A public proof of concept is available for this vulnerability.
  • Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
  • Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
  • Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
  • Not confirmed: The user expressed doubt about the validity of the vulnerability.
  • Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.



Related by attack behaviour

Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.