On October 28, 2026, Bitcoin Core published three security advisories — CVE-2026-117349, CVE-2026-117350, and CVE-2026-117346. Bitcoin Core is the node software — the program that independently verifies and relays transactions — run by most of the network's computers. Two of the three bugs let another node on the network grow a target's memory usage without bound until it crashes; one of those two is confirmed to spare nodes running Linux and affect only Windows, macOS, and other non-Linux systems. The third lets a miner (a network participant that produces new blocks), under narrow and expensive conditions, overflow the files a node keeps for undoing short chain reorganizations (brief periods where the network temporarily disagrees on the latest blocks). Fixes shipped for every maintained version line; none of the three is known to have been exploited. CoinDesk reports that the memory-growth bug was flagged by an automated, large-language-model-assisted code-scanning tool on October 23, confirmed by a Bitcoin Core contributor the same day, and fixed four days later.

The timing matters because the policy governing this disclosure changed six days earlier. Bitcoin Core has historically held medium- and high-severity bugs under embargo for roughly a year — until the last affected release lost support — so operators could upgrade before the details became public. On October 22, the project merged a proposal, submitted by developer Antoine Poinsot, creating a new "easily discoverable" classification: a bug findable "through a simple [language-model] prompt" skips that embargo, moving straight to a fixed release and a public advisory (per CryptoTicker's account of the pull request, which quotes Poinsot calling the old embargo "the wrong tradeoff" that "achieves little but delays the availability of a fixed release").

This sits under Security, Decentralization & Durability — 18 of the framework's 100 weighted points, the dimension that covers client software and the durability of the network layer independent of consensus rules. This cadence used the same dimension on October 21 (Solana's Alpenglow upgrade, a consensus-threshold redesign) and October 23 (Starknet's governance vote, a voting-power concentration question). This is a third, different argument under it: not how consensus is designed or how votes are weighted, but how fast a bug moves from "exists" to "known to everyone, including attackers," and who controls that clock.

The sharper point is one the framework's own structure doesn't catch. None of CryptoGrade's nine hard gates would register this episode. Gate 2 checks for unaudited or previously-exploited contracts — Bitcoin has no smart contracts for that gate to examine. Gate 9 checks for a history of exploit — these three bugs were found, confirmed, and patched before anyone is known to have used them, so there is no exploit to log. A gate structure built around contract audits and realized exploits is, on its own terms, blind to a security event that happened entirely inside a functioning disclosure process. That is not a defect unique to this framework — gates that fire only after the fact cannot see risk that lives in client software rather than a deployed contract. Whether a security score should weigh patch cadence and disclosure posture as a signal of their own, separate from the gate structure, is a real open question — this piece names the gap rather than answering it or proposing a change; a rules-based framework's method changes through the product, not through a blog post arguing it should.

One detail argues that client diversity is a genuine mitigant and not just a talking point: CVE-2026-117350 spared Linux nodes outright. A network where every operator ran the same client on the same operating system would have had no unaffected subset to fall back on; Bitcoin's platform mix is why this bug was serious for some operators and a non-event for others, in the same week.

The wider signal is the embargo math, not the bugs. The most reviewed codebase in the industry — the kind any scoring framework would call maximally audited by default — still produced three unknown issues from one automated review pass, the same month the project rewrote its disclosure clock to handle that becoming routine. A discovery method cheap enough to run constantly changes what "already audited" can honestly mean, for every client, not only this one.