# BSV Blockchain SDK has an Authentication Signature… 📦 📦 npm Not in CISA KEV MEDIUM severity # BSV Blockchain SDK has an Authentication Signature Data Preparation VulnerabilityGHSA-vjpq-xx5g-qvmm MEDIUM [Fix: bsv-blockchain/ts-sdk@d8cf693](https://github.com/bsv-blockchain/ts-sdk/commit/d8cf6930028372079d977138ae9eaa03ae2f50bb) GHSA-vjpq-xx5g-qvmm is a medium-severity (CVSS 5.4) CWE-573 vulnerability in @bsv/sdk. A fix is available for @bsv/sdk — see the affected versions and patch details below. Also known as[CVE-2025-69287](/vulnerability/CVE-2025-69287) Published Feb 17, 2026 Updated Feb 22, 2026 Affected 1 pkg Patched 1 / 1 Exploits None indexed Exploitation data as of Oct 30, 2026 · OSV.dev, NVD, FIRST.org (EPSS) ## Exploitation Status ### Proof-of-concept exploit code exists - CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation. Exploitation and automatability from CISA’s SSVC triage for GHSA-vjpq-xx5g-qvmm. ## EPSS Exploitation Probability [via FIRST.org ↗](https://www.first.org/epss/) 0.3%probability of exploitation in next 30 days Lower Risk+0.04% Lower risk than most CVEs28th percentile — riskier than 28% of all scored CVEsHighest risk 0.00%0.28%0.56%0.84%0.1%0.3%May 26Aug 26Oct 26 Probability of exploitation in the next 30 days, from [FIRST.org EPSS](https://www.first.org/epss/). ## How urgent is this, really ## Where this sits among everything scored ## Real-World Exposure 1 pkg affected How broadly this vulnerability is actually deployed: weekly install volume shows current usage, and reverse-dependency count shows how many other packages break if it stays unpatched. 139other npm packages depend on this — each one inherits the vulnerability until it's patched upstream `@bsv/sdk`npm 19Kdownloads / week ## Description ## BRC-104 Authentication Signature Data Preparation Vulnerability #### Summary A critical cryptographic vulnerability in the TypeScript SDK's BRC-104 authentication implementation caused incorrect signature data preparation, resulting in signature incompatibility [between SDK implementations](https://github.com/F1r3Hydr4nt/brc104-cross-language-tests) and potential authentication bypass scenarios. #### Details The vulnerability was located in the `Peer.ts` file of the TypeScript SDK, specifically in the `processInitialRequest` and `processInitialResponse` methods where signature data is prepared for BRC-104 mutual authentication. **Vulnerable Code Locations:** - `ts-sdk/src/auth/Peer.ts` lines 527-531 (signing) - `ts-sdk/src/auth/Peer.ts` lines 584-590 (verification) **Root Cause:** The TypeScript SDK incorrectly prepared signature data by: 1. Concatenating base64-encoded nonce strings: `message.initialNonce + sessionNonce` 2. Then decoding the concatenated base64 string: `base64ToBytes(concatenatedString)` This produced ~32-34 bytes of signature data instead of the correct 64 bytes. **Buggy Implementation (Before Fix):** ``` // CRITICAL BUG: Concatenating base64 strings before decoding data: Peer.base64ToBytes(message.initialNonce + sessionNonce) ``` **Correct Implementation (After Fix):** The fix properly decodes each base64 nonce individually, then concatenates the byte arrays: ``` data: [ ...Peer.base64ToBytes(message.initialNonce), ...Peer.base64ToBytes(sessionNonce) ] ``` **Why This is Critical:** BRC-104 authentication relies on cryptographic signatures to establish mutual trust between peers. When signature data preparation is incorrect: - Signatures generated by the TypeScript SDK don't match those expected by Go/Python SDKs - Cross-implementation authentication fails - An attacker could potentially exploit this to bypass authentication checks #### PoC The cross-language test suite demonstrates this vulnerability: 1. **Setup**: Use identical nonces and cryptographic inputs across TypeScript, Python, and Go SDKs 2. **Vulnerable behavior**: TypeScript SDK produces different signature data than Go/Python reference implementations 3. **Impact demonstration**: Authentication attempts between TypeScript clients and Go/Python servers fail due to signature mismatch **Test Evidence:** ``` // Buggy approach (produces ~32-34 bytes) const concatenatedB64 = INITIAL_NONCE_B64 + SESSION_NONCE_B64; const buggyResult = Array.from(Buffer.from(concatenatedB64, 'base64')); // Correct approach (produces 64 bytes) const correctResult = [...INITIAL_NONCE_BYTES, ...SESSION_NONCE_BYTES]; ``` **Base64 Padding Short Circuit Analysis:** The vulnerability occurs because base64 padding characters (`=`) act as early termination signals for base64 decoders. When concatenating base64 strings before decoding: 1. **Individual nonces:** Each 44-character base64 string decodes to 32 bytes 2. **Concatenated string:** 88-character string containing padding in the middle 3. **Decoding result:** Base64 decoder stops at the first `=` padding character, producing only 32 bytes instead of 64 **Example with test data:** - `INITIAL_NONCE_B64`: `"QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUE="` (44 chars → 32 bytes) - `SESSION_NONCE_B64`: `"QkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkI="` (44 chars → 32 bytes) - **Concatenated:** `"QUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUFBQUE=QkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkJCQkI="` - **Buggy decode:** Only 32 bytes (decoder stops at first `=`) - **Correct decode:** 64 bytes (32 + 32, decoded separately then concatenated) #### Impact **Vulnerability Type:** Cryptographic signature verification bypass **Severity:** Critical (CVSS 9.1 - Critical) **Affected Systems:** - TypeScript SDK clients attempting to authenticate with Go or Python SDK servers - Any BRC-104 implementation relying on cross-SDK compatibility - Mutual authentication protocols using the affected signature preparation **Who is Impacted:** - Applications using the TypeScript SDK for BRC-104 authentication - Systems requiring cross-language/SDK authentication compatibility - Any peer-to-peer authentication scenarios where TypeScript clients communicate with non-TypeScript servers **Potential Attack Vectors:** - Authentication bypass through signature verification failure - Man-in-the-middle attacks if authentication is silently ignored - Denial of service through failed authentication attempts The fix ensures all SDKs now produce identical cryptographic signatures, restoring proper mutual authentication across implementations. ## Affected Packages 1 total 1 fixed Ecosystem Package Vulnerable range Fix 📦npm `@bsv/sdk` all versions 2.0.0`npm install @bsv/sdk@2.0.0` ## Detection & mitigation playbook Open-source dependency 1. ### Detect Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @bsv/sdk, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version. 2. ### Fix Update @bsv/sdk to 2.0.0 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-vjpq-xx5g-qvmm is resolved across your whole dependency graph. 3. ### Workarounds Put an independent control in front of the weakness: restrict the affected endpoint or interface to trusted networks, require an additional authentication factor or proxy-level check, and invalidate existing sessions and credentials in case the flaw has already been used. ## Frequently Asked Questions \# BRC-104 Authentication Signature Data Preparation Vulnerability ### Summary A critical cryptographic vulnerability in the TypeScript SDK's BRC-104 authentication implementation caused incorrect signature data preparation, resulting in signature incompatibility \[between SDK implementations\](https://github.com/F1r3Hydr4nt/brc104-cross-language-tests) and potential authentication bypass scenarios. ### Details The vulnerability was located in the \`Peer.ts\` file of the TypeScript SDK, specifically in the \`processInitialRequest\` and \`processInitialResponse\` methods where signature data is prepar O3 Security · Impact-Aware SCA ### Is GHSA-vjpq-xx5g-qvmm in your dependencies? Find it across npm, including transitive dependencies. [Scan my dependencies](/book-demo) [How O3 SCA works](/impact-aware-sca)