Two Bitcoinjs-lib Bugs Could Hide Massive Miner Fees: Why Your Wallet App Might Approve a Costly Transaction Without Warning

Two security flaws in one of the most widely used Bitcoin software libraries could quietly drain funds from wallet applications that never realized anything was wrong. The bugs sat inside bitcoinjs-lib, the open-source toolkit that developers around the world embed in wallets, trading tools and payment software to build and sign Bitcoin transactions. On October 26, the maintainers published security advisories and patched releases, and the episode is a useful reminder for everyday crypto users that the weakest link in a wallet is often not the blockchain itself but the ordinary software stacked on top of it.

What went wrong inside bitcoinjs-lib

Bitcoinjs-lib is a JavaScript library that applications use to construct transactions, manage keys and handle the partially signed Bitcoin transaction format known as PSBT, defined by BIP 174. That format lets separate tools pass transaction data and signatures between one another — signing, combining signatures, finalizing inputs and extracting the finished transaction are distinct steps, even when a single application performs several of them. It is precisely this flexible, multi-step pipeline where the two flaws crept in.

According to the October 26 security advisories published by the bitcoinjs-lib maintainers, both bugs involve how the library accounts for miner fees. A Bitcoin transaction’s fee is simply the difference between the value of its inputs and the value of its outputs. Understate the value of an input and the calculated fee looks far smaller than the amount actually being paid. The patched releases — versions 5.2.2, 6.1.9 and 7.0.4 for their corresponding release lines — force the fee calculation to treat every input honestly.

How a valid signature can hide a giant fee

The first flaw is subtle. Signing a transaction and calculating its fee are separate operations, and the bug allowed them to consult different values for the same input. Signing used the full previous transaction record, while fee accounting preferred a conflicting record carrying a smaller value. The result: the vulnerable software could authorize a perfectly legitimate transaction while evaluating the wrong fee entirely.

The advisory describes a demonstration on bitcoinjs-lib version 7.0.1 in which a transaction’s true fee was 900,000,000 satoshi — roughly nine whole bitcoin at the smallest unit of the currency — while the library reported just 200 satoshi. The signature verified successfully, and the extraction step completed without triggering the default excessive-fee warning. In other words, every safeguard built on top of the library’s accounting would have been silently satisfied while nearly the entire input value was diverted to a miner.

The second advisory covers a related failure mode: finalized inputs whose input-value records were missing entirely. The fee calculator counted those inputs as zero. Critically, an already-signed PSBT imported from another party could reach this calculation without needing any further signing operation — a realistic scenario for coordination tools, multisig setups and exchanges that assemble transactions from externally prepared files. The advisory’s hypothetical example showed a true fee of 91,000 satoshi reported as only 1,000 satoshi.

Who is actually at risk

There is an important limit to the damage these bugs can cause. The defects do not forge signatures and do not create unauthorized transactions. Actual loss requires a legitimate, authorized transaction to be broadcast and accepted by the network; when it is, the excess value quietly becomes a miner’s fee rather than landing in an attacker’s pocket. That distinction makes exploitation less dramatic than a classic exchange hack, but no less painful for a user whose wallet software approves a payment and accidentally torches the balance difference.

The real risk concentrates in applications that import the library and trust its fee calculation or excessive-fee safeguard without independently verifying the outputs being spent. For the conflicting-record flaw, the affected releases are 5.2.0 through 5.2.1, 6.0.0 through 6.1.8 including 6.1.0-rc.0, and 7.0.0-rc.0 through 7.0.3. The missing-record flaw affects those same version 6 and version 7 ranges, plus 5.1.0 through 5.2.1 in the version 5 line. Any wallet or service built on those versions inherits the vulnerability until it upgrades.

How the maintainers fixed it

The remediation, described in the project’s public commit history, gives signing and fee accounting a shared method for resolving previous outputs, rejects conflicting values or scripts outright, and requires an explicit amount for every input during fee calculation. It also clears cached fees and extracted transactions whenever relevant metadata changes or PSBTs are combined, closing the door on stale values lingering from earlier steps.

For maintainers who cannot upgrade immediately, the advisories recommend a disciplined workaround: independently verify the value of every referenced output before trusting any fee figure. Reject conflicting records before signing, and confirm every input value before extracting a final transaction. It is old-fashioned bookkeeping discipline, but it is exactly the kind of check that catches an understated input before the network does.

Why this matters beyond one library

For everyday investors, the lesson is less about bitcoinjs-lib specifically and more about the supply chain that sits underneath every wallet. Open-source libraries are reused across thousands of applications, and a single accounting flaw can propagate quietly into hardware wallet companion apps, browser wallets, merchant tooling and exchange back-ends. Most users have no way to inspect which library versions their wallet vendor has bundled.

The practical takeaways are straightforward. Prefer wallets from teams that respond quickly to upstream security advisories — the patch here shipped with coordinated disclosures, which is a sign of a healthy maintenance process. Watch for wallet updates in the coming weeks and install them promptly, since vendors will be folding the patched releases into their own builds. And if you use multisig or coordination tooling that passes PSBT files between parties, be aware that imported transactions deserve the same skepticism as ones you build yourself.

The bitcoinjs-lib episode ended without a headline-grabbing theft, but only because maintainers caught the flaws before someone else did. In crypto, the difference between a security advisory and a nine-figure loss is often just timing — and this time, the good guys moved first.