AI helped find bugs in Bitcoin Core. The serious question is not whether a chatbot can take over Bitcoin, but whether software maintainers and node operators can turn validated findings into effective protection.
On 28 October, Bitcoin Core disclosed three vulnerabilities discovered through an automated large language model scan. Two carry Medium ratings; the third is Low. Their significance lies in specific failure conditions and a changing disclosure policy, not a demonstrated attack on Bitcoin’s monetary rules.
The disclosures make a sharper point than either technological triumphalism or panic: making bugs easier to find increases the importance of the less glamorous work that follows.
Three findings, not one Bitcoin catastrophe
The TCP urgent-data advisory describes a connected malicious peer overwhelming a node’s memory. A mechanism intended to pause incoming data could be bypassed, allowing the processing queue to grow without limit and crash the node.
Its scope is crucial: Windows, macOS and BSD are affected; Linux is explicitly unaffected by this particular flaw. Bitcoin Core calls the issue “Medium severity and easily discoverable”. A remote crash is consequential, but it is not evidence of stolen coins or control over the network.
The second Medium-severity advisory concerns outgoing announcements accumulating for paused peers using an older protocol capability. A malicious peer could pretend not to support BIP31’s ping messages and avoid the normal disconnection mechanism.
The project gives maximum memory-growth rates of 2 MB per hour per inbound peer and 5 MB per hour per outbound peer. These are conditional, per-peer rates, not measured network-wide losses. Nodes using the blocksonly setting are much less affected because transaction announcements account for most queued messages.
The small print is the security story
The Low-severity undo-file flaw concerns data a node needs when reversing blocks during a chain reorganisation. Under extreme conditions, file-position limits could corrupt or prevent writing that data, causing shutdown.
Bitcoin Core describes exploitation on 64-bit systems as impractical: the preparation would require mining several thousand specially constructed blocks, followed by tightly constrained conditions for a reorganisation. The advisory also discusses theoretical corruption of a node’s record of unspent coins under even more precise control; it does not report this happening.
The fix expands file-position handling, including on Windows. Yet 32-bit systems and nodes storing blocks on FAT32 remain affected by file limits. “Install the update and every environment is covered” would therefore be a materially misleading summary.
None of these advisories reports exploitation. That is not proof nobody attempted an attack; it is the limit of the evidence available here. Equally, the Linux exemption belongs to the TCP issue, not a blanket declaration that Linux nodes cannot be affected by the other findings.
Disclosure has to account for rediscovery
All three advisories credit Elias Rohrer’s Project Loupe at Spiral for automated LLM scanning, with Gregory Sanders validating and surfacing the findings to Bitcoin Core. That human verification matters: model output became actionable security work through technical scrutiny, not merely because a machine produced it.
Bitcoin Core’s security disclosure policy now treats easily discoverable vulnerabilities differently. It includes issues findable with minimal effort, “such as through a simple LLM prompt”, and calls for point releases for maintained major versions and an advisory as soon as possible, without the standard severity-dependent embargo.
The logic is defensible. A long silence is less protective if others can cheaply rediscover the same weakness. The paused-peer issue was independently rediscovered, while the undo-file advisory records independent reports too.
But speed creates a management problem, not a licence to abandon testing. Faster patches can compress the time available for pre-release checks. That is a trade-off to manage; these disclosures do not establish that the resulting releases were unsafe.
The operational test comes after discovery
The repair timeline is not three identical five-day turnarounds. Project Loupe reported the undo-file issue on 8 July, the paused-peer issue on 15 September and the TCP issue on 23 October. Fixes were merged and backported on 26 October, according to the advisories.
Their timelines list Bitcoin Core 31.2 and 32.1 on 27 October, followed by 29.5 and 30.4 on 28 October alongside public disclosure. Operators need to match their maintained branch, operating system and storage setup to the relevant advisory, rather than treating a version headline as a complete risk assessment.
The counterpoint to alarmism is not complacency. Disclosing a validated weakness and shipping a repair is evidence of a functioning response process, but publication alone cannot show how many affected nodes have adopted it.
AI-assisted discovery deserves credit. The harder standard is whether findings are validated, scope is explained, repairs are tested and deployment is checked. Confusing a vulnerable node with a conquered network makes that practical work harder to see.
Bitcoin’s defence is not the promise that no bug will be found. It is the discipline applied when one is.
