Two bitcoinjs-lib bugs could hide a huge fee from the app that signs it, but no loss is known

The maintainers of bitcoinjs-lib, the open-source JavaScript library that many Bitcoin apps use to build and sign transactions, disclosed on 26 October two high-severity PSBT fee bugs: a crafted partially signed bitcoin transaction (PSBT) could hide or understate its real fee. In one test described in the first GitHub advisory, a transaction paying 900,000,000 satoshis (9 BTC) in fees was reported by the library as paying 200 satoshis. Fixed versions have been on npm since 13 October. No loss, no exploitation and no affected wallet have been reported.

Both advisories were published on GitHub at 18:40 UTC on Monday 26 October, rated High, as part of a batch of six. Neither of the two fee bugs has a CVE number. The fee advisories name 7.0.4, 6.1.9 and 5.2.2 as the fixed versions. Another advisory in the batch, on blockchain and earns a reward, which makes rewriting history very expensive.">proof-of-work checks, is only fixed in 7.0.5, 6.1.10 and 5.2.3, published earlier that Monday, so those are the versions that cover every advisory affecting each release line.

The library is widely used. npm counted 740,832 downloads in the week from 20 to 26 October, and tens of thousands of npm packages list it as a dependency, many of them indirectly or only for testing. That figure says nothing about which apps are exposed, and neither the advisories nor the press so far name one.

Two bitcoinjs-lib bugs make the fee look smaller than it is

Both bugs sit in the way the library adds up the value of a transaction’s inputs. The fee of a Bitcoin transaction is never written in it: it is whatever the inputs bring in minus what the outputs pay out. If the library counts the inputs wrong, its fee figure is wrong, and so is the safety check that relies on it.

Conflicting UTXO records: 9 BTC of fees shown as 200 satoshis

The first advisory, GHSA-4mfv-5394-26c7, covers a PSBT input that carries two records of the coin it spends: the full previous transaction (nonWitnessUtxo) and a short summary of the output (witnessUtxo). When the two disagree, the signing code used the full transaction, while the fee accounting took the amount from the summary without checking it.

The maintainers’ reproduction on version 7.0.1 uses an input worth 1,000,000,000 satoshis whose summary claims 100,000,200. The real fee is 900,000,000 satoshis. getFee() returns 200. The signature verifies, and extractTransaction() hands back the finished transaction without the fee-rate warning that should have stopped it.

The advisory says the excess becomes a miner fee and does not by itself go to whoever built the PSBT. The victim is the signer, who pays a fee far above what the app showed.

Inputs with no UTXO record counted as zero

The second advisory, GHSA-h52v-8xwg-7j95, concerns finalized inputs that carry neither record. The library simply added nothing for them. Its worked example has two inputs of 10,000 and 90,000 satoshis, with amount data only on the first, and 9,000 satoshis of outputs. The true fee is 91,000 satoshis; the library reported 1,000. An excessive fee could then pass the maximumFeeRate check at extraction.

This advisory stresses that the bug creates no signature and spends no coin without permission. Money is lost only if such a transaction is broadcast and confirmed. CryptoSlate, which reported the bugs on 28 October, draws the same line: without a signed, valid transaction that the network accepts, nobody loses anything.

Affected and patched bitcoinjs-lib versions

The two fee bugs touch three release lines. The table below gives the ranges from the advisories and the npm publish times of the fixes, all on 13 October 2026, according to the npm registry.

The 6.x ranges include 6.1.0-rc.0. Version 7.0.5 was published at 16:00 UTC on 26 October, 6.1.10 at 15:41 and 5.2.3 at 15:35, a few hours before the advisories went public. The 13-day gap between the first fixes and the disclosure is not explained in the advisories; giving users time to upgrade before details go public is a common practice, but no source says that was the reason here.

The fix commit, by the developer landabaso, adds one shared routine that every part of the library now uses to find the coin an input spends. It prefers the full previous transaction, checks its hash and output index, and throws an error if a summary record is also present with a different value or script. Fee calculation now requires an amount for every input and fails otherwise. Both bugs were reported by 0xaudron and Ali-Kalout; junderw reviewed the second fix.

Four more advisories in the same batch, one with a CVE

The other four advisories published on 26 October, also rated High, have nothing to do with fees. They matter to apps that parse or check blocks, not to ordinary wallets that only sign.

• GHSA-8vv3-6qpc-gpw6: duplicated nodes in the merkle root computation let a forged list of transactions pass as valid. It is the only one of the six with a CVE, CVE-2026-107846, and was fixed in 7.0.2, 6.1.8 and 5.2.1.
• GHSA-4vm8-79jj-j6w4: the proof-of-work check accepted invalid compact targets (the nBits field). It affects versions from 2.2.0 up to 7.0.4, 6.1.9 and 5.2.2, is fixed in 7.0.5, 6.1.10 and 5.2.3, and has no fix for versions before 5.0.0.
• GHSA-8247-5gp7-95qh and GHSA-88jr-9qj4-ccm4: two denial-of-service bugs, one from quadratic copying in Block.fromBuffer and one from repeated integer reads, affecting 7.0.0-rc.0 to 7.0.2 only and fixed in 7.0.3.

So an app on 7.0.4, 6.1.9 or 5.2.2 has the two fee fixes but still lacks the proof-of-work fix. Version 7.0.5 closes all six; 6.1.10 and 5.2.3 close every one that applies to their line, since the two denial-of-service bugs never touched 5.x or 6.x.

How PSBT fees work, and why the signer must check the amounts

A PSBT, defined in BIP 174, is a transaction passed between several parties before it is complete: a coordinator builds it, co-signers or hardware devices add signatures, and someone finally broadcasts it. The specification itself shows a 2-of-3 multisig workflow and a manual coinjoin, and says the format lets offline signers such as hardware wallets sign without direct access to the set of unspent coins. Our guide to how crypto transactions work explains inputs, outputs and fees from the start.

The catch is that a PSBT does not prove the amounts it claims. The input records are data supplied by whoever built the file. A careful signer checks them against the real previous transactions before it trusts any fee figure, and libraries such as bitcoinjs-lib offer a fee-rate guard as a last line of defence. These two bugs fooled that guard, which is why the advisories warn apps that rely on getFee() or the default check.

Who is exposed to the PSBT fee bugs: Coindaro’s reading

Neither the maintainers nor CryptoSlate have listed exposed apps. On Coindaro’s reading of the advisory text, exposure needs three things together: an app built on an affected version, a PSBT that comes from someone else (a co-signer, a coordinator server, a dApp), and an app that trusts the library’s fee figure before it signs and broadcasts. The first advisory does say exploitation requires the app to accept the conflicting data and carry on without checking the real coins itself; the rest of this section is our interpretation.

A wallet that builds its own transactions from coin data it fetched itself is not the case the advisories describe, in our view. If you are unsure which kind of tool you use, our page on crypto wallets and custody sets out the main types.

Not the Electrum fee-bump flaw from 25 October

The timing invites confusion. Three days earlier Coindaro covered a different fee-related flaw in Electrum, where a rogue server hid a user’s real pending payment and the user’s own fee bump then signed a theft. That bug was exploited and at least one user lost funds. It lives in Electrum, a Python wallet fixed in version 4.8.3, and needs a malicious server.

The bitcoinjs-lib bugs are in a JavaScript library, involve no server, and have no reported victim. The excess fee would go to miners rather than to an attacker’s address. Only the word fee links the two stories.

Bitcoin wallet security: what developers and users should do now

For developers, the fee advisories ask for 7.0.4, 6.1.9 or 5.2.2 at minimum. Going straight to 7.0.5, 6.1.10 or 5.2.3 also picks up the proof-of-work fix. Check the lockfile too, because the library often arrives through another package. If you cannot upgrade, verify the referenced outputs yourself and reject any PSBT whose two UTXO records disagree. Turning the fee checks off is not a workaround, the maintainers add.

Wallet users cannot patch a library themselves. What they can do is update their apps, and when a PSBT comes from someone else, look at which coins are being spent and what each one is worth, rather than the fee line alone, before approving. A fee that looks far too low for the size of the payment deserves a second look. The wallet you sign with is only as careful as the data it checks.

No European regulator has said anything about the advisories. Firms in the EU that run wallets for clients under MiCA and build on JavaScript tools are in the same position as everyone else: the fix is an update.

What is still unknown about the bitcoinjs-lib advisories

No app has been named as affected, by the maintainers or by CryptoSlate. No exploitation in the wild has been described. The reporters are known only by their GitHub handles, and the two fee bugs have no CVE number so far. The next thing to watch is whether wallet and multisig projects that depend on bitcoinjs-lib publish their own notices about which versions they shipped.