CVE-2026-40069: Integrity Verification Failure in BSV Ruby SDK ARC Broadcaster

The bsv-sdk library provides Ruby applications with native interfaces to interact with the Bitcoin SV network. A core feature of this SDK is the Application Registry Connector (ARC) broadcaster, which submits serialized transactions to ARC nodes for inclusion in the blockchain mempool.

This SDK is heavily utilized in wallet backends, merchant payment processors, and automated trading platforms. These applications rely on the broadcaster component to confirm whether a transaction has been successfully propagated to the network before updating internal state logic, such as adjusting user balances or fulfilling orders.

CVE-2026-40069 represents a critical integrity validation failure within this transaction broadcasting flow. The vulnerability is classified as CWE-754, representing an improper check for exceptional conditions within the response parser.

Because the SDK's result parser fails to correctly interpret multiple terminal failure states returned by the ARC protocol, it effectively lies to the calling application. The SDK reports failed transactions as successful broadcasts, creating an immediate state divergence between the application's internal ledger and the actual blockchain network.

The vulnerability stems from an incomplete failure-state predicate within the lib/bsv/network/arc.rb file. When an application submits a transaction via the ARC broadcaster, the protocol returns a JSON response containing a txStatus field and an optional extraInfo field.

The original implementation of the handle_broadcast_response method utilized a narrow, fail-open approach for determining transaction success. The code explicitly checked the txStatus against a limited constant array containing only the values REJECTED and DOUBLE_SPEND_ATTEMPTED.

If the node returned a status that did not exactly match these two strings, the SDK defaulted to treating the response as a successful broadcast. This assumption violates the ARC protocol specification, which defines several other terminal states indicating transaction rejection.

Specific statuses ignored by the SDK include INVALID for script execution failures, MALFORMED for serialization errors, and MINED_IN_STALE_BLOCK. Furthermore, the SDK did not inspect the extraInfo field for the ORPHAN keyword, which indicates the transaction references non-existent parent inputs and cannot be added to the mempool.

The patch implemented in commit 4992e8a265fd914a7eeb0405c69d1ff0122a84cc addresses the vulnerability by enforcing a fail-closed validation model. The primary change expands the array of rejected statuses.

# Vulnerable Implementation
REJECTED_STATUSES = %w[REJECTED DOUBLE_SPEND_ATTEMPTED].freeze
 
def handle_broadcast_response(response)
  return false if REJECTED_STATUSES.include?(response['txStatus'])
  true
end

The patched implementation explicitly adds INVALID, MALFORMED, and MINED_IN_STALE_BLOCK to the rejection filter. This ensures that standard protocol errors correctly trigger a false return value, preventing the application from trusting failed broadcasts.

# Patched Implementation
REJECTED_STATUSES = %w[
  REJECTED
  DOUBLE_SPEND_ATTEMPTED
  INVALID
  MALFORMED
  MINED_IN_STALE_BLOCK
].freeze
 
def handle_broadcast_response(response)
  return false if REJECTED_STATUSES.include?(response['txStatus'])
  
  has_orphan_status = response['txStatus']&.upcase&.include?('ORPHAN')
  has_orphan_info = response['extraInfo']&.upcase&.include?('ORPHAN')
  
  return false if has_orphan_status || has_orphan_info
  return false if response['txid'].nil?
  
  true
end

The developers also introduced a case-insensitive substring check for the ORPHAN keyword across both relevant response fields. Additionally, the patch includes protocol hardening measures, such as verifying that the txid field is present and correctly populated, and ensuring the HTTP Content-Type header strictly adheres to application/json.

Exploitation of CVE-2026-40069 requires the attacker to construct a transaction that is syntactically valid enough to be parsed by the application but functionally invalid according to network consensus rules.

The attacker begins by identifying an application endpoint that accepts raw transaction hex and processes it using a vulnerable version of bsv-sdk. The attacker then crafts an orphan transaction by referencing fictitious inputs, ensuring the transaction will be rejected by the ARC node's mempool validation.

When the application submits this transaction to the ARC node, the node responds with an HTTP 200 OK status, which is standard for many proxy implementations. The response body contains {"txStatus": "SEEN_ON_NETWORK", "extraInfo": "ORPHAN"}.

The vulnerable SDK implementation parses this JSON response. Since SEEN_ON_NETWORK is not in the limited REJECTED_STATUSES array, the SDK returns a success value. The application proceeds to execute its business logic, such as crediting a user account or releasing digital goods, based on a transaction that does not actually exist on the blockchain.

The vulnerability carries a CVSS v3.1 base score of 7.5, reflecting a high-severity integrity impact. The confidentiality and availability metrics are scored as None, as the flaw does not expose sensitive data or allow for denial-of-service conditions.

The primary consequence is severe state divergence between the application's internal database and the actual blockchain. Applications relying on the SDK for payment verification are directly exposed to financial loss, as attackers can spoof successful payments without expending valid network assets.

The attack vector is network-based and requires no elevated privileges or user interaction. Any unauthenticated user capable of interacting with the application's transaction submission workflow can trigger the vulnerability.

While no active exploitation has been observed in the wild, the exploitation methodology is straightforward. The regression tests included in the patch repository provide clear instructions on how to simulate the ARC node responses necessary to trigger the flaw.

The definitive remediation for this vulnerability is upgrading the bsv-sdk package to version 0.8.2 or later. This release introduces the required robust failure-state validation and orphan transaction detection.

Developers must update their application dependency configurations to specify the safe version and run the package manager to apply the update. After applying the patch, application server processes must be restarted to ensure the new library code is loaded into memory.

For environments where immediate patching is not possible, developers should implement defensive programming measures around the broadcast functionality. Applications can manually inspect the raw ARC node response, if accessible, to verify the exact txStatus and extraInfo fields before continuing execution.

Alternatively, applications can introduce a secondary validation step. After broadcasting the transaction, the application can query a trusted block explorer or a direct node RPC interface to confirm the transaction's presence in the mempool before executing state-altering business logic.