Bitcoin Core developers have disclosed three vulnerabilities that affected older versions of the software after the 29.x release series reached end of life. The issues include one high-severity bug and two medium-severity flaws, all of which had already been fixed in maintained releases before the disclosure.
The advisories were summarized in Bitcoin Optech’s latest newsletter, which said the fixes were included in Bitcoin Core 29.2 and 30.0, with two of the three also patched in 28.3. All affected release series are now unsupported, and developers said users should move to a maintained version.
Three advisories published after end of support
According to the newsletter, Antoine Poinsot posted three security advisories to the Bitcoin-Dev mailing list. The timing of the disclosure was tied to support status: the vulnerabilities were made public two weeks after the last affected release reached end of life.
The most serious issue was described as a bug in which block template creation could halt during a chain reorganization involving TRUC sibling eviction. In practice, that meant some mining nodes could stop producing new block templates under those conditions.
Two additional issues were rated medium severity. One involved inbound Tor connections incorrectly receiving -whitelist permissions. The other could cause block processing to stall through witness malleation.
Which versions received fixes
Bitcoin Optech said all three vulnerabilities were fixed in Bitcoin Core 29.2 and 30.0. It added that the first two issues, the block-template problem and the Tor permission flaw, were also addressed in Bitcoin Core 28.3.
Because every affected release line has now reached end of life, the project’s guidance is not to remain on those versions. The newsletter’s summary points users toward maintained releases rather than unsupported older branches.
Separate Tor-related hardening landed in code changes
The same newsletter also highlighted a separate Bitcoin Core code change related to Tor. In Bitcoin Core pull request #36142, developers fixed command injection through the Tor control endpoint.
That change adds validation for onion service keys and IDs. If a cached key fails validation, the onion service becomes unavailable until the cached key is deleted and the node is restarted, at which point a new onion address is generated.
Although listed in the newsletter’s notable code changes rather than in the three disclosed advisories, the update shows continued attention to Tor-related edge cases in the software.
Other network and testnet work in focus
Beyond the vulnerability disclosure, the newsletter pointed to other active areas of Bitcoin infrastructure work. Anthony Towns outlined a plan to mine the genesis block for testnet5, the proposed successor to testnet4 under BIP95.
Mining is expected to start after mainnet reaches its next difficulty adjustment, with the genesis block committing to a mainnet block hash at or after that height. A public pool is intended to be used so developers do not get a head start. Even after genesis is mined, node parameters, DNS seeds, faucets, and explorers will still be needed before broad use.
The newsletter also revisited degraded compact-block reconstruction seen from mid-July to mid-October. Investigators linked the poor performance to chains of rune mints whose similarly structured transactions created mempool and block-propagation difficulties, forcing nodes to request missing transactions more often.
Next confirmed step
The immediate confirmed takeaway from the disclosure is that the affected Bitcoin Core release series are no longer supported and that fixes are already present in maintained versions. For operators still on older branches, the relevant update path is to a currently maintained release.
Separately, the next concrete milestone mentioned in the newsletter is the planned start of testnet5 genesis mining after the next mainnet difficulty adjustment, followed by updates to BIP95 once the genesis block values are known.
Source: bitcoinops.org