CVE-2026-40069: 
Ruby vulnerability analysis and mitigation

CVE-2026-40069 is an improper failure detection vulnerability in the BSV Ruby SDK (bsv-sdk) affecting the BSV::Network::ARC broadcaster component. The flaw causes ARC responses with txStatus values of INVALID, MALFORMED, MINED_IN_STALE_BLOCK, or any ORPHAN-containing extraInfo/txStatus to be silently treated as successful broadcasts, when they should be treated as failures. All versions from 0.1.0 through 0.8.1 are affected; the vulnerability was identified on April 8, 2026, during a cross-SDK compliance review and publicly disclosed on April 9, 2026. It carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Feedly).

The root cause is classified as CWE-754 (Improper Check for Unusual or Exceptional Conditions). In lib/bsv/network/arc.rb (lines ~74–100 in affected versions), the REJECTED_STATUSES predicate only checks for REJECTED and DOUBLE_SPEND_ATTEMPTED, diverging from the TypeScript reference SDK which additionally recognizes INVALID, MALFORMED, MINED_IN_STALE_BLOCK, and any response containing ORPHAN in extraInfo or txStatus. Because the missing code path simply does not exist, any ARC endpoint returning one of these unhandled statuses — whether due to a malformed transaction, a transient fork creating an orphan condition, or a hostile/misbehaving ARC node — causes the broadcaster to return a success result to the caller. Additional protocol divergences (wrong Content-Type header, missing XDeployment-ID/X-CallbackUrl/X-CallbackToken headers) compound the risk but are not the primary security defect (GitHub Advisory, Fix PR).

The vulnerability is a pure integrity issue with no confidentiality or availability impact. Applications that gate business-critical actions on a successful broadcast result — such as releasing goods, marking invoices paid, treating a token as minted, or progressing a workflow — are tricked into trusting transactions that were never actually accepted by the BSV blockchain network. This can lead to incorrect application state, financial loss, or fraudulent fulfillment of obligations based on transactions that the network rejected (GitHub Advisory).

1. Identify a target application: Locate a Ruby application using bsv-sdk versions 0.1.0–0.8.1 that gates business logic (e.g., payment confirmation, token minting, order fulfillment) on the return value of BSV::Network::ARC#broadcast.
2. Craft an invalid or malformed transaction: Construct a BSV transaction that is syntactically or semantically invalid — for example, one with an invalid script, incorrect sighash, or referencing a non-existent UTXO — that an ARC endpoint will reject with a txStatus of INVALID or MALFORMED.
3. Submit the transaction via the vulnerable broadcaster: Invoke the application's transaction broadcast flow, causing BSV::Network::ARC#broadcast to submit the crafted transaction to the ARC endpoint.
4. ARC returns a failure status: The ARC endpoint responds with a txStatus of INVALID, MALFORMED, MINED_IN_STALE_BLOCK, or an ORPHAN-containing value.
5. Exploit the missing failure check: Because the Ruby SDK's failure predicate does not include these statuses, the broadcaster returns a success result to the calling application instead of raising a BroadcastError.
6. Trigger business logic on a failed transaction: The application, believing the transaction was successfully broadcast, executes downstream actions (e.g., marks an invoice paid, releases goods, mints a token) based on a transaction that was never accepted by the network (GitHub Advisory, Fix PR).

• Application Logs: Absence of BroadcastError exceptions in application logs despite ARC endpoint logs showing INVALID, MALFORMED, MINED_IN_STALE_BLOCK, or ORPHAN txStatus values for submitted transactions.
• Blockchain State: Business actions (payments marked as received, goods released, tokens minted) that have no corresponding confirmed transaction on the BSV blockchain — verifiable via a block explorer such as WhatsOnChain.
• ARC Endpoint Logs: ARC server-side logs recording rejection of transactions with statuses not in {REJECTED, DOUBLE_SPEND_ATTEMPTED} that correspond to transactions submitted by the vulnerable application.
• Application State Inconsistency: Discrepancies between the application's internal transaction status records (showing success) and the actual on-chain state (transaction absent or unconfirmed) (GitHub Advisory).

Primary remediation: Upgrade bsv-sdk to version 0.8.2 or later, which expands the failure predicate to include INVALID, MALFORMED, MINED_IN_STALE_BLOCK, and any ORPHAN-containing response, matching the TypeScript reference SDK. Users of bsv-wallet should upgrade to version 0.3.4 or later, which tightens its bsv-sdk dependency to >= 0.8.2, < 1.0, ensuring the fix is pulled in transitively. Workaround (if immediate upgrade is not possible): Independently verify broadcast results out-of-band (e.g., query WhatsOnChain or another block explorer) before gating any integrity-critical application actions on the ARC broadcaster's success response (GitHub Advisory, Release v0.8.2).

The vulnerability was identified internally during a structured cross-SDK compliance review on April 8, 2026, comparing the Ruby SDK against the TypeScript reference implementation. The project's Security Specialist noted: "Silently treating failure statuses as success is a serious integrity concern," and the Domain Expert added: "ARC missing failure-status set means broadcasts that are actually INVALID/MALFORMED are treated as success; domain-critical." The fix was voted on by the project team (8 AGREE, 0 DISAGREE) and shipped as a paired patch release alongside two other high-severity findings (GitHub Issue #305).