The Bitcoin Core team on Oct. 28 disclosed three vulnerabilities identified through automated code scanning with a large language model. The flaws could increase nodes’ memory usage or crash them, prompting developers to issue fixes for all supported major versions and change their disclosure rules.

An automated analyzer identified all three vulnerabilities as part of Project Loupe, which Elias Rohrer is developing at Spiral. Developer Gregory Sanders reviewed the findings before they were submitted to the Bitcoin Core security team.

Three vulnerabilities affecting Bitcoin Core nodes

The first vulnerability, reported on Oct. 23, affected the handling of urgent TCP data on non-Linux systems. A connected attacker could send specially crafted data that bypassed message-queue size limits and caused unbounded memory growth, potentially crashing Bitcoin Core nodes running on Windows, macOS and BSD.

Developers classified the vulnerability as medium severity. Linux nodes were not affected because they use a different mechanism to monitor network connections.

The second flaw also caused uncontrolled data accumulation in memory. A connected node could claim to use an outdated protocol version and delay message processing. According to Bitcoin Core’s notice, memory usage could rise by as much as 2 megabytes per hour for each inbound connection and 5 megabytes per hour for each outbound connection.

The automated scanner detected the second vulnerability on Sept. 15. Another developer found it independently on Sept. 21.

The third vulnerability, rated low severity, affected files that store data needed for blockchain reorganizations. Miners could create blocks that caused these undo files to overflow. If a corresponding reorganization occurred later, some nodes could crash.

On 64-bit systems, exploiting the flaw would require substantial resources. Developers estimated that preparing an attack could take about one month of block mining by the entire network. On Windows and 32-bit systems, a crash could occur without such a reorganization, and the official notice said restarting the node would not resolve the problem.

The fix does not fully eliminate the issue for 32-bit systems or nodes storing blocks on older drives using the FAT32 file system. In other cases, developers addressed the vulnerability in part by switching to 64-bit integers for storing file positions.

Developers revise disclosure policy

Developers released fixes in Bitcoin Core versions 29.5, 30.4, 31.2 and 32.1. Versions 31.2 and 32.1 became available on Oct. 27, followed by versions 29.5 and 30.4 on Oct. 28. Details of the vulnerabilities were published on Oct. 28.

Bitcoin Core had previously allowed medium-severity vulnerabilities to remain undisclosed for as long as one year, giving node operators time to upgrade. On Oct. 22, the project changed its policy for vulnerabilities that can be discovered quickly with an LLM.

Under the new policy, developers must prepare fixes for every supported major version as quickly as possible when a vulnerability is considered easy to discover. They will publish the related advisory once those fixes are available rather than waiting for the standard embargo period to expire.

Other vulnerabilities remain subject to the usual disclosure schedule. Bitcoin Core publishes details of low-severity bugs two weeks after releasing the major version containing the fix. It discloses medium- and high-severity vulnerabilities two weeks after the latest affected release reaches the end of its life cycle.

The Bitcoin Core release notes also said developers planned to disclose three additional medium- and high-severity vulnerabilities fixed in version 30.0 in two weeks.

Source: Incrypted