Executive Summary

The vulnerability in the BSV Ruby SDK affects the ARC broadcaster component, which incorrectly treats certain failure statuses as successful broadcasts. Specifically, from versions 0.1.0 to before 0.8.2, the ARC broadcaster only recognized REJECTED and DOUBLE_SPEND_ATTEMPTED as failures, while statuses like INVALID, MALFORMED, MINED_IN_STALE_BLOCK, or any status containing ORPHAN were silently treated as successful. This causes applications relying on the broadcaster's success response to mistakenly trust transactions that were never accepted by the network.

This flaw leads to a critical integrity issue where actions gated on broadcaster success, such as releasing goods or marking invoices paid, could be triggered based on unconfirmed or invalid transactions. The vulnerability was fixed in version 0.8.2 by expanding the failure detection to include these additional failure statuses and aligning behavior with the TypeScript reference SDK.

Useful 0 Not Useful 0

Impact Analysis

This vulnerability can impact you by causing your application to trust and act upon transactions that were never accepted by the BSV network. Because the ARC broadcaster incorrectly signals success for certain failed transactions, any critical actions gated on broadcast success—such as releasing goods, marking invoices as paid, or progressing workflows—may be executed erroneously.

This leads to integrity violations where your system's state or business processes could be compromised, potentially resulting in financial loss, incorrect transaction records, or workflow errors.

Useful 0 Not Useful 0

Detection Guidance

This vulnerability can be detected by verifying whether the ARC broadcaster in the bsv-ruby-sdk is incorrectly treating certain failure statuses as successful broadcasts. Specifically, check if the broadcaster only recognizes REJECTED and DOUBLE_SPEND_ATTEMPTED as failures, while treating INVALID, MALFORMED, MINED_IN_STALE_BLOCK, or any ORPHAN-containing statuses as successes.

To detect this on your system, you can monitor transaction broadcast responses and verify if transactions with these failure statuses are being silently accepted. Additionally, you can cross-check broadcast results using external block explorers or network monitoring tools to confirm if transactions reported as successful by the ARC broadcaster were actually accepted by the network.

Since the vulnerability is in the Ruby SDK versions before 0.8.2, you can check the installed version of the bsv-sdk gem with the following command:

• gem list bsv-sdk

If the version is below 0.8.2, your system is vulnerable.

To test the broadcaster behavior, you could attempt to broadcast transactions that would trigger failure statuses like INVALID or MALFORMED and observe if the SDK raises errors or silently treats them as successes.

Useful 0 Not Useful 0

Mitigation Strategies

The immediate and recommended mitigation is to upgrade the bsv-ruby-sdk to version 0.8.2 or later, which fixes the vulnerability by properly handling failure statuses and raising exceptions on broadcast failures.

You can upgrade the SDK using the following command:

• gem install bsv-sdk -v 0.8.2

If you are using the sibling gem bsv-wallet, ensure it is upgraded to version 0.3.4 or later, which pins the bsv-sdk dependency to versions >= 0.8.2.

As a temporary workaround before upgrading, avoid relying solely on the ARC broadcaster's success response to gate critical actions. Instead, verify broadcast results out-of-band using block explorers or other network verification methods.

Useful 0 Not Useful 0

Compliance Impact

The vulnerability causes applications relying on the ARC broadcaster's success response to mistakenly trust transactions that were never accepted by the network. This leads to integrity violations such as releasing goods, marking invoices paid, or progressing workflows based on unconfirmed transactions.

Such integrity violations can impact compliance with standards and regulations that require accurate and reliable transaction processing, such as GDPR or HIPAA, by potentially causing unauthorized or incorrect actions based on false transaction confirmations.

Workarounds include verifying broadcast results out-of-band before trusting the broadcaster's success response and avoiding gating critical actions solely on ARC broadcaster success.

Useful 0 Not Useful 0