Bitcoin Core patches vulnerability allowing fund redirection in partially signed transactions

Bitcoin Core has patched a vulnerability in partially signed transactions that could allow attackers to redirect funds to unintended recipients without accessing private keys. The fix highlights how even cryptographically sound signatures can authorize the wrong transaction if wallet software does not independently validate the payment details users approved.

• Bitcoin Core merged a safeguard on September 25 into its master development branch blocking risky SIGHASH_SINGLE signing requests.
• The vulnerability does not expose private keys but allows valid signatures to work on changed transaction recipients under specific conditions.
• Wallet providers must review their own SIGHASH_SINGLE handling rather than wait for a Bitcoin Core release containing the fix.

• Sept. 25 Date Bitcoin Core merged the safeguard into its development branch
• Oct. 2 Date Bitcoin Optech highlighted the update in its newsletter

CryptoSlate reported that Bitcoin Core has added a check to prevent signing of partially signed Bitcoin transactions, or PSBTs, where the cryptographic commitment between an input and its intended output breaks down. The change, merged into the project’s master development branch on September 25, targets a narrow flaw in SIGHASH_SINGLE, a signing mode designed to bind an input to the output at the corresponding position. When that output is missing from the transaction, the protection fails in different ways depending on whether the input is a legacy address or a SegWit v0 address. Bitcoin Optech highlighted the update on October 2, drawing wider attention to a cryptographic gap that does not compromise key security but does compromise payment authorization.

How the signature flaw allowed spending redirection

For legacy Bitcoin inputs, a missing output in SIGHASH_SINGLE mode produces a signature committed to a fixed hash value rather than to any specific payment destination. Bitcoin Core developers said that signature can then be reused against other unspent outputs controlled by the same private key when the same structural conditions are present. The flaw creates an authorization problem for wallets and signing devices: software could present one payment to the user for approval while producing a signature that does not cryptographically guarantee that the approved recipient remains unchanged.

SegWit v0 transactions retain stronger protections because signatures still commit to the specific coin being spent and its amount, but the destination output can remain unbound.

Bitcoin Core’s fix blocks signing at the cryptographic layer

Bitcoin Core already rejected this edge case through its raw-transaction signing interface, but the PSBT code path including walletprocesspsbt could still sign it. The new change moves the check into Bitcoin Core’s shared signature-creation logic, preventing affected legacy and SegWit v0 inputs from being signed while allowing other valid inputs in the same transaction to proceed. Bitcoin Improvement Proposal 174, which defines PSBTs, already recommends that signers reject unacceptable signing modes and recommends SIGHASH_ALL when no alternative is specified. The Bitcoin Core change enforces that boundary at the point of signature creation rather than relying on downstream wallet software to reject dangerous requests.

PSBTs are commonly used to coordinate transactions between software wallets, hardware devices and offline signers by allowing transaction builders to pass information to a separate signer without giving that system control of the private keys. The fix reinforces a separation of concerns: the signer must verify that its cryptographic commitment matches the transaction details the user actually authorized, independent of whether the key itself remains secure.

Wallet providers face immediate decisions while waiting for a release

The September 25 merge occurred in Bitcoin Core’s development branch, and as of October 4 the project’s published release listings had not identified a fixed version or confirmed whether the change will be backported to earlier supported versions.

That timeline leaves wallet providers and hardware-signing integrations with a more immediate responsibility: review their own handling of SIGHASH_SINGLE requests rather than waiting for a Bitcoin Core release to enforce the same protection. Developers using Bitcoin Core’s PSBT logic in their own products should apply the same guard. The pull request merging the fix documents the technical details and the conditions under which the vulnerability manifests, giving wallet teams the information needed to audit their signing paths now.

The BlockWest read. This is a signature validation problem, not a key compromise. Institutions and custodians using hardware signers or multi-party signing setups should confirm their signing software validates that the user-approved output destination matches the signature’s cryptographic commitment, regardless of which Bitcoin Core version they deploy. The vulnerability exposes why wallet architecture matters as much as key storage.

Wallet developers and hardware-signer integrations should audit their SIGHASH_SINGLE handling now and confirm they reject unacceptable signing modes, rather than wait for Bitcoin Core’s next release to distribute the safeguard downstream.

BlockWest is a news publication. Nothing here is investment advice. Read our disclaimer and editorial policy.