bitcoinjs-lib Maintainers Disclose Two High-Severity Bitcoin (BTC) Fee Vulnerabilities

Two High-Severity Advisories for bitcoinjs-lib

Two vulnerabilities rated high severity in bitcoinjs-lib, a widely used JavaScript library for building Bitcoin (BTC) transactions, can make a partially signed transaction display a fee far below what the network will actually charge. The library's maintainers published two security advisories on October 26 classifying both flaws as high severity, alongside corrected releases for each affected version series. Both flaws sit in the fee-accounting layer that wallets present to users before a transaction is approved. If a user signs on the strength of the app's figure, the broadcast transaction can carry a larger mining fee than the screen promised. Neither flaw touches Bitcoin (BTC) price or the network's consensus rules; both concern the accounting a wallet shows at the signing step.

The scope covers applications that process PSBTs through the library while depending on its fee calculation or its guard against excessive fees. PSBT, defined by BIP 174, is the interchange format that moves transaction data and signatures between apps and signing devices; BIP 174 requires each input to carry the previous output record it spends, the value signers use to compute and show the fee, the structure that took shape after Segregated Witness made signature data a distinct input type. The first flaw appears when a single input carries two conflicting previous-output records at once. The signing step reads the real value, while the fee calculation can pick the lower figure from the other record. In the maintainers' reproduction case, an actual fee of 900,000,000 satoshis was computed as 200 satoshis. Signature verification passed, and extraction produced no default fee-rate warning. The maintainers note that this number is a reproduction of the bug, not a measured user loss.

What the Flaws Can and Cannot Do

The second flaw appears when an input that has already been signed carries no previous output record at all. When the library aggregates that input's value as zero, the fee computes lower than the transaction actually pays. In the maintainers' example, a real fee of 91,000 satoshis was displayed as 1,000 satoshis. Both cases show the same outcome: the displayed fee and the over-fee block can stop reflecting what the transaction is really worth.

Neither flaw can forge a signature or move Bitcoin (BTC) without the user's approval. A loss requires an approved, valid transaction to be broadcast, accepted and confirmed, at which point the entire fee, including any excess, is paid to the miners who perform Crypto Mining under the network's Proof of Work rules; the surplus is not returned to the sender.

Versions affected differ within v5. The conflicting-record issue spans 5.2.0 to 5.2.1, while the missing-record issue reaches back to 5.1.0 and also covers 5.2.1. Both flaws affect the full v6 range of 6.0.0 to 6.1.8 and v7 builds from 7.0.0-rc.0 through 7.0.3. Fixes landed in 5.2.2, 6.1.9 and 7.0.4. The maintainers published 15 advisories the same day, covering other issues as well, and point to 5.2.3, 6.1.10 and 7.0.5 as the current releases for each series.

The guidance to developers is concrete: audit direct and indirect dependencies for the affected ranges, and where an upgrade is not possible, verify each input's previous output value independently and reject inputs whose values conflict or are missing. Whether individual wallets are exposed, and whether any real loss has occurred, remains unconfirmed. The advisories establish the defect and its reach inside the library; they do not count the wallets built on it, so the population actually at risk stays outside what these documents measure.

Why Fee Displays Are a Trust Boundary

For a library embedded across wallet stacks, the fee figure is the number a user trusts before approving, and these advisories show that layer can be decoupled from the transaction's true cost. The practical response sits with Bitcoin development teams: dependency trees need auditing, and fee displays deserve independent verification rather than blanket library trust. The signing ecosystem has been through fragmented adoption before, as when the Taproot upgrade at block 709,632 left wallet support optional and uptake split across the market. Until apps confirm they run patched versions, users should treat any displayed PSBT fee as advisory, not final.