Artificial intelligence has discovered dangerous vulnerabilities in Bitcoin. Users should update the software

Artificial intelligence helped detect three vulnerabilities in Bitcoin Core, the software used by most publicly available Bitcoin nodes. One of the vulnerabilities allowed a remote attacker to crash a node running Windows, macOS or BSD. The fixes are now available, but one of the issues still persists in the configuration section. We explain who the warnings apply to and why they do not mean that Bitcoin’s cryptographic security has been compromised.

On Wednesday, October 28, 2026, Bitcoin Core developers disclosed information about three vulnerabilities discovered during automatic code analysis using the language model (LLM). Two were classified as medium-severity threats, the third as a low-severity threat. Patched versions 31.2 and 32.1 were released on October 27, while versions 29.5 and 30.4 were released a day later, in parallel with the public release of details.

One of the bugs allowed the Bitcoin Core node to be remotely disabled

The most immediate threat concerned the handling of network connections. On Windows, macOS and BSD systems, Bitcoin Core uses the mechanism select() to monitor the activity of TCP connections. Under certain conditions, the software responded incorrectly to the so-called TCP urgent data (TCP urgent data), allowing you to bypass the limit on the amount of data placed in memory.

The attacker did not have to gain access to the victim’s computer or take over his private keys. It was enough that it was connected to a vulnerable node and transmitted appropriately crafted data. RAM could then fill up until the program crashed. In the official description of the bug, the developers stated that a malicious network participant could relatively easily disable the node connected to it on the indicated systems.

This particular vulnerability did not affect Linux. Bitcoin Core uses a different connection monitoring mechanism based on poll(). However, one should not conclude from this that all Linux installations were safe: the second of the disclosed vulnerabilities could also affect them.

Two more vulnerabilities: memory exhaustion and file corruption

The second problem was also related to memory, but it involved the way nodes communicated. A malicious network participant could pose as an older client that does not support the BIP 31 ping mechanism and then intentionally delay receiving messages. Bitcoin Core continued to accumulate messages intended for such a connection, allowing the data queue to grow without any apparent limit.

According to the vulnerability documentation, memory consumption could increase by up to 2 MB per hour for each incoming connection and 5 MB per outgoing connection. This was a slower attack than previously described, but over many connections it could gradually exhaust the device’s resources. Nodes operating in mode were less exposed -blocksonlywhich do not send the standard stream of messages about unconfirmed transactions.

The third gap concerned the so-called files undoused when reorganizing the blockchain. Under extreme conditions, the miner could create valid blocks that would cause these files to exceed write limits. This could lead to a node failure and the need to rebuild the blockchain data indexes. However, developers assessed the effective use of this bug in typical 64-bit configurations as impractical, among other reasons because of the need to extract thousands of specially prepared blocks.

In this case, an important exception remains: patches do not completely address vulnerabilities on 32-bit systems or in installations storing block files on FAT32 partitions. Operators of such nodes should consider changing the configuration rather than just updating the program. Details are described in a separate security message.

How much of the Bitcoin network could have been exposed?

The scale of risk cannot be equated with the number of BTC holders. The vulnerabilities affected specific Bitcoin Core installations, not the bitcoins themselves stored on the wallets. According to Coin Dance statistics available on October 29, there were approximately 18.4 thousand websites operating on the network. publicly reachable nodes, including approximately 16.4 thousand using Bitcoin Core. This represented nearly 89% of monitored devices.

This does not mean that all of these nodes were vulnerable. The actual threat depended on the installed version, operating system and connection settings. Public lists also do not include all nodes that do not accept incoming connections. In practice, the most important factors are possible interruptions in the operation of devices that independently verify blocks and transactions or provide data to other services.

Are you reading us? Add bitcoin.pl to your preferred sources on Google

How to check Bitcoin Core version and install patch?

Those running their own node should verify that they are using a patched version. As of October 29, 2026, these are Bitcoin Core 29.5, 30.4, 31.2 and 32.1. The latest release is 32.1. Please remember that the 29.x branch has already reached the end of its support period, so version 29.5 is better treated as an interim solution rather than a final solution.

Check the program version. In the graphical application, open the “About Bitcoin Core” information. In the terminal of the running node you can use the command bitcoin-cli getnetworkinfo and read the fields version and subversion.

Download the correct version from the official source. The current release 32.1 is available on the Bitcoin Core download repository. Select the file for your system and verify the checksum and release signatures according to the project instructions.

Make sure to make a backup before installation. If you use a wallet on Bitcoin Core, please secure a current copy of it. Then properly close the program, complete the installation, and run it again.

Confirm the update. Check the version of the running node, and in the case of a server installation, also its logs and the correctness of connections to the network. If you are using a 32-bit or FAT32 system, also verify the restrictions described in the file message undo.

It was artificial intelligence that found the errors. What does this mean for Bitcoin’s security?

All three vulnerabilities were discovered during automated scans conducted by Project Loupe, an initiative of Spiral and Block. The project uses AI models to analyze open source software code related to Bitcoin. Elias Rohrer is responsible for its development, among others. The reports were then reviewed by Gregory Sanders and forwarded to the Bitcoin Core security team, with fixes prepared by the project’s developers.

The history of these errors shows both the possibilities and limitations of artificial intelligence. AI helped identify real vulnerabilities, but only their technical verification allowed us to assess the scale of risk and prepare safe changes. Two problems were also discovered independently by other researchers. The Bitcoin Core team has changed the rules for disclosing vulnerabilities that can be found relatively easily, also using LLM: in such cases, fixes for supported versions and warnings are to be made available as quickly as possible.

Do the detected vulnerabilities mean that Bitcoin has been hacked?

NO. None of the three disclosed vulnerabilities indicate a breach of Bitcoin cryptography or the possibility of obtaining private keys remotely using the described errors. They concern the operation of specific software: connection handling, memory management and saving data needed for chain reorganization. An attack on node availability is a serious technical problem, but it is different than taking funds from a wallet.

Someone storing BTC on a hardware wallet or app that does not run its own Bitcoin Core is not required to install Bitcoin Core due to these warnings. Instead, it should regularly update the software it actually uses and download it from trusted sources.

Official announcements provide no evidence of these three vulnerabilities being used in real attacks. However, once the details are made public, there is no point in postponing the update. For node operators, it is primarily a matter of the stability of their own infrastructure, and for the entire network it is another example of why open code, independent audits and quick implementation of patches remain important.