Bitcoin Core has changed its security disclosure policy after developers found that some vulnerabilities can be rediscovered with minimal effort, including a simple prompt to an AI model.
Summary
- Bitcoin Core merged its revised security policy on October 22, adding a fast disclosure route for flaws that are easy to rediscover.
- The new route promises a fix for each of the three maintained major versions alongside a public advisory.
- Other low severity bugs remain on a two week disclosure schedule after a major release, while medium and high severity flaws may wait longer.
- Version 32.0’s notes identify three medium or high severity flaws fixed in version 30.0 whose details are due after the newer release.
- Bitcoin Core tagged version 32.0 on October 21, leaving versions 30.x, 31.x and 32.x inside its three version maintenance window.
The project’s October 22 policy update creates a faster route for those bugs. Maintainers plan to ship a point release for every supported major version as soon as possible and publish a security advisory alongside the fixes. Other vulnerabilities retain the existing disclosure timetable. No particular new flaw was announced with the policy change, and an AI-generated report is not automatically a real vulnerability. The change concerns the time between a verified discovery, a patched release and public details.
Bitcoin nodes validate blocks and transactions locally, and exchanges, custodians and other services build operations around them. A release may make patched software available across supported versions, yet the operators of those systems decide when to install it. Bitcoin Core does not update itself on every machine. Public disclosure can help people identify a problem and install the fix, while giving an attacker information that an unpatched node might still reveal through its network behavior.
— crypto.news (@cryptodotnews) October 12, 2026JUST IN: Avalanche founder warns AI could steal billions by exploiting crypto software bugs before breaking ECDSA
Emin Gün Sirer says vulnerabilities in wallets, libraries and system code pose a more immediate risk than quantum attacks on existing cryptography, making software… pic.twitter.com/qu8LRItMep
The new policy separates discovery from severity
Bitcoin Core already classified vulnerabilities as critical, high, medium or low according to their effects and how they could be exploited. A remotely triggered crash under default settings may be high severity; a flaw that requires a nonstandard configuration or causes limited disruption may fall lower. The revised security advisory policy adds a separate question about how easily someone could find the issue. Its example is a simple prompt to a large language model, but the category is not limited to flaws found using AI.
The distinction prevents a common misreading. “Easily discoverable” does not mean “low severity.” A bug can be simple to find and dangerous to affected nodes. Conversely, an obscure issue may have a serious effect if exploited, yet still warrant more time before the details are made public. Maintainers assess a report during triage and choose whether the fast route applies. The posted policy gives the criterion and the planned response, but it does not publish a mechanical threshold for deciding which prompts, tools or skills qualify as minimal effort.
Antoine Poinsot, who proposed the website change, said in the pull request discussion that maintainers had received more reports of flaws that were easy to rediscover. He attributed much of the change to language models lowering the effort needed to find certain problems or identify a fix that developers tried to keep discreet. In his account, withholding details offers less protection when another person can independently find the weakness quickly. The same embargo can delay a fixed release for operators who remain on a supported older branch.
For a report placed in the new category, Bitcoin Core says it will publish a point release with the fix for each maintained major version and an advisory at the same time. “As soon as possible” describes an intention, not a fixed number of hours from the first report. Developers still need to confirm the issue, write and review a patch, test it on each branch and prepare releases. The policy does not promise that an unmaintained release will receive a patch or that all operators will have upgraded before the advisory appears.
The older embargo could outlast several releases
Ordinary disclosures follow a different clock. The policy says low severity vulnerabilities are disclosed two weeks after a major version containing the fix is released. Medium and high severity issues are disclosed two weeks after the last affected release reaches end of life, approximately a year after a major version first included the fix. Maintainers make a preannouncement two weeks before revealing an embargoed issue, stating how many vulnerabilities were fixed and their severity levels. Critical flaws sit outside that standard schedule and require a response tailored to the incident.
The version 32.0 release notes give a concrete comparison. They say three medium or high severity vulnerabilities fixed in version 30.0 will be disclosed two weeks after the newer release, while there were no low severity vulnerabilities fixed in 32.0 to disclose on that schedule. Version 30.0 is dated October 10, 2025, in Bitcoin Core’s lifecycle table. The version 32.0 release schedule records its tag on October 21, 2026. Those dates are 376 days apart, an arithmetic comparison of the older fix date and newer tag, not the project’s announced date for an individual advisory.
The notes do not identify the components or exploitation conditions of those three flaws. Under the standard process, a fix can remain available in a newer version while details stay private until the older affected branches leave the maintenance window. The new route changes that calculus only for bugs maintainers judge readily discoverable. It does not cancel the long timetable for harder-to-find medium and high severity cases.
A past disclosure shows the older path in practice. Bitcoin Core disclosed CVE-2024-52911 in May 2026 after the flaw had already been fixed in version 29.0, released in April 2025. A specially crafted block could trigger a use-after-free condition in the script interpreter and crash vulnerable nodes. Producing a block with enough proof of work made the attack costly, and the project considered remote code execution unlikely. The gap between fix and public details was part of the prior disclosure approach; it does not prove that the old issue would have met today’s easy-discovery criterion.
Three maintained versions define who gets a fix
Bitcoin Core’s software lifecycle says maintainers support the latest three major versions. When a new major release arrives, the oldest of the three reaches end of life and generally stops receiving security fixes. With version 32.0 tagged on October 21 and its release notes saying version 29.x and older have reached end of life, the branches for the new fast route are 30.x, 31.x and 32.x. A point release for each of those branches would let an operator on 30.x apply a targeted patch without adopting every feature and behavior change in 32.0 immediately.
The 32.0 release-candidate cycle began on September 14, and the project tagged the stable version on October 21. The distinction between a release tag, a binary and an installed node matters. The schedule shows a 32.0 tag; official distribution and the operator’s own deployment are subsequent steps. Its lifecycle page still displayed a “TBA” release date for 32.x at the time this feature was prepared, even though the release schedule showed the tag. The 32.0 release notes say version 29.x and older have reached end of life. Bitcoin Core has yet to update the 32.x date displayed on its lifecycle table.
A branch that remains supported is not automatically patched. The policy says fixes will be backported to each maintained major version, and the lifecycle page says the bar for backporting generally rises as a branch ages. The new easy-discovery promise is more specific for the security bugs it covers. Maintaining three patched lines requires review and testing across differences in code, rather than simply copying one commit into three directories. A fix that applies cleanly to one branch can need different work on another. Bitcoin Core has not specified a fixed time limit for that work.
Operators beyond the three branches face a different decision. Version 29.x may still start and validate ordinary blocks after end of life, but it generally will not receive a new security point release. An operator running it must move to a maintained branch to obtain future patches. Bitcoin Core recommends the latest maintenance release of the newest major version the operator can adopt. A business with custom integrations or wallet data may need its own compatibility checks before making that move. End of life describes the project’s support boundary, not a switch that shuts old software off on a given day.
Bitcoin Core’s lifecycle page makes another distinction that can get lost in a security alert. A major version is a branch, while a minor version is the maintenance update on that branch. Someone running 30.0 and someone running 30.3 are both on 30.x, but they have not necessarily installed the same fixes. If the project cuts a new 30.x point release for an easily found bug, merely reporting that a service runs “version 30” would not establish protection. The complete version number and the release’s fix list are needed. This is why a company saying it has upgraded its nodes without naming the deployed build leaves the central question unresolved.
Release notes for version 32.0 describe how a normal upgrade starts with shutting down the old software and waiting for it to finish before installing the replacement. Node operators with transaction indexes, wallets or connected applications may have additional checks to perform. The project’s documentation says maintenance releases normally avoid introducing major new features, which makes a patched point release narrower than a jump to a new major branch. Every deployment still has to be tested against the software around it.
The patch can be public before most nodes install it
Bitcoin Core has no central operator that can push an update to every node. An individual running a home node may download a release soon after seeing an advisory. A custodian or exchange may test an upgrade against internal services, wallet systems and monitoring before changing production nodes. A mining pool has another set of validation and block-building dependencies. These are operational possibilities, not a measured list of how quickly each group installed any particular Bitcoin Core update; no adoption count accompanied the policy change.
A public advisory changes the information available to both sides. It can describe the affected versions, impact and fix so operators can act. It can also provide clues to someone testing old nodes for the same weakness. Poinsot’s argument is that the attacker may already find an easily discoverable flaw without the advisory, while operators have less chance to patch if fixed point releases are withheld until a later major version. That position is a reason to accelerate the repair, not evidence that the exposure disappears once the release goes live.
The method of distribution matters as much as the notice. A node operator needs to obtain the correct binary or source package, check its authenticity under the project’s release process, stop the current software safely and restart on a version appropriate to the deployment. A warning on social media is not a substitute for the signed release and official advisory. Bitcoin Core’s version 32 notes tell users to shut down an older version and wait for it to finish before installing new software. The steps are mundane, but a hurried production change can introduce its own outage if service dependencies are not ready.
Automatic monitoring can help an organization notice a release. It cannot decide whether its running node is affected by a vulnerability that depends on a particular feature or configuration. An advisory should give enough detail to prioritize the relevant systems. During the interval between publication and deployment, network-facing nodes remain a practical concern. The project has not published a measured median time for operators to install maintenance releases, so the question in the headline cannot be answered with a network-wide number as of October 24.
AI reports require verification before any public alert
The Bitcoin Red Team has supplied a striking example of the scale AI-assisted reviews can produce. In August, crypto.news reported 4,962 potential issues across 390 Bitcoin-related projects during the group’s first 29.8 hours of review. The group classified 720 as high or critical and said more than one fifth of the potential findings had been reproduced at the reporting date. Those are the group’s figures for a range of projects, not a count of Bitcoin Core vulnerabilities or a verified tally of exploitable bugs.
The difference between a generated finding and a confirmed flaw is central to the new policy. A model can suggest a path through code, but maintainers must reproduce it, establish whether an attacker can reach it and determine which releases are affected. A finding in a test harness may not be present in production; a missing check in one code branch may have a compensating control elsewhere. Severity requires examining real preconditions and consequences. The fast disclosure classification comes after that technical work, not when an AI tool prints a plausible explanation.
The project repository describes code review and testing as bottlenecks for development. A flood of low-quality reports could consume the same scarce attention needed to fix a serious issue. Conversely, a credible, reproducible report can give maintainers an earlier warning. Bitcoin Core’s security reporting instructions direct sensitive findings to its security email address instead of a public issue. The update does not make it sound practice to post unverified exploit details openly while maintainers are still checking them.
Bitcoin security groups requested frontier AI access in August to support defensive work. Bitcoin Core’s separate policy change addresses flaws that other users of the same tools may rediscover. Poinsot said maintainers had received more such reports and concluded that withholding a fix offered little protection in those cases.
The security policy’s four severity examples show why one warning cannot fit every node. A remotely triggered crash under default settings can disrupt a publicly connected service. A flaw requiring a special feature enabled on a local network affects a smaller group. A problem in block template construction can be urgent for a miner without creating the same immediate action for a merchant whose node only verifies incoming blocks. In each case, “easy to rediscover” measures how readily an attacker can learn about the weakness, not which operators have the affected configuration. The advisory has to carry both pieces of information if the new timetable is to be useful.
Bitcoin Core’s historical advisory list includes denial-of-service conditions that slow block propagation, exhaust memory or crash a node, alongside a past inflation bug that threatened consensus. These are not interchangeable classes of incident. The policy explicitly excludes critical bugs from the standard timetable, preserving room for a response shaped around the risk to the entire network. The new easy-discovery route should therefore be read as an added disclosure decision within the project’s security process, not as a claim that AI has changed Bitcoin’s consensus rules.
Developers disagreed about the warning itself
The policy discussion includes a substantial objection to simultaneous release and public warning. Bitcoin developer Antoine Riard argued on the pull request that an advisory could provoke an unnecessary rushed migration among users who are not affected by the particular bug. His example distinguished a block-template issue that miners would need to address urgently from a case in which merchants could take a more careful upgrade path. An undifferentiated security alarm can make every operator feel it must change production systems immediately.
Riard did not dispute that some bugs are easy to discover. He questioned the timing and content of an alert sent to operators who face different levels of risk. A fast release could give miners, merchants, wallets and exchanges a patched branch at once, while an advisory explains different exposure for each group. If the advisory is too vague, affected operators may not recognize their urgency; if it is too broad, unaffected ones may take disruptive action. The final policy retained the promise of an advisory alongside the point releases and did not specify a single template for describing every affected role.
Poinsot’s opposing case is that longer secrecy can keep supported older branches from receiving a fix, and a readily found bug is unlikely to stay hidden merely because the project waits. Both positions accept that deployment is slow and a public notice can move behavior. They differ over which risk dominates for a particular verified flaw. The policy makes “easy to discover” a triage judgment, leaving maintainers to choose the fast path only when they think the patch delay is harder to justify than the disclosure risk.
Neither argument establishes that publication is always harmless or that secrecy always protects people. A very simple flaw affecting a default network service could make speed paramount. A flaw affecting a narrow, nondefault setup might merit highly specific instructions even if a model can describe it easily. The severity categories and the new discovery assessment should together shape the release note. Bitcoin Core has not published a roster of future cases, and no post-change incident yet establishes how well the approach works in the field.
Core Lightning offers a different operational example
Bitcoin Core’s policy governs Bitcoin Core, not every program in the Bitcoin ecosystem. Core Lightning developers faced their own AI-generated report volume in August and confirmed that several submissions described real flaws. In October, the team warned operators of older nodes after reports of attacks against systems running version 26.06.7 or earlier. It urged an upgrade to a newer release. The team had not identified the attack method publicly or confirmed user losses in that warning, so the reports should not be treated as proof of a particular exploit or applied to Bitcoin Core’s code.
The Lightning example shows why an available fix does not complete the security response. Operators may continue using older software after patched releases exist. Its August 26.06.7 source was initially withheld for two weeks so operators could install the release before prospective attackers studied changes; later source publication and the October warning followed a different disclosure sequence from Bitcoin Core’s new easy-discovery route. The software, network layer and threat were different. The common practical fact is that a notice only protects a system when the relevant operator understands it and deploys the correct update.
Some Lightning node operators were told that running a daemon offline could temporarily limit exposure while it continued monitoring the blockchain. A Bitcoin Core operator should not import that instruction without checking its own application’s requirements. A full node used by a wallet, exchange or Lightning service can have obligations that continue even when network connectivity changes. The Bitcoin Core advisory for a specific flaw will need to say whether a temporary configuration change is useful. No blanket workaround appears in the October 22 policy.
The difference between “available” and “installed” is easiest to see when a flaw does not affect every setup. A miner may run a block template service beside its validating node. A custodial platform may isolate its Bitcoin Core process from the public internet but allow internal programs to call its RPC interface. A home user may run the default network settings with a built-in wallet. One point release can fix all three deployments, yet the immediate exposure and the time required to test an update can differ. Bitcoin Core’s public policy does not try to assign one universal deadline to those operators.
A well-scoped advisory could state the affected versions and settings, the damage a successful exploit could cause, and whether the attack needs network access, local access or a particular user action. The project has used those distinctions in past advisory categories. Operators can then compare their own configurations with the described conditions. The Oct. 22 amendment promises to publish an advisory with a fix for the easy-discovery group, but the exact facts disclosed will depend on the first verified issue classified that way.
The first fast disclosure will establish the pace
The written change gives maintainers a new route but supplies no case study yet. The measurable sequence begins with a verified report and classification, moves to patches for all three maintained branches, and ends with signed point releases and an advisory. Dates on those steps would show how quickly the project can backport a fix and whether its public notice arrives only when each branch is ready. A release that covers two of three maintained lines would not match the published promise for the new category.
Operators’ uptake is harder to observe. Publicly reachable nodes may advertise software versions, but network crawls see only a subset of deployments and version strings need not disclose every private service. Exchanges and custodians may use internal nodes that never accept inbound public connections. A researcher who reports a percentage upgraded should explain the sample and its blind spots. Without that, the number could understate the share of production infrastructure still exposed or overstate it by counting dormant public nodes.
The version 32.0 notes direct operators to the project’s announcement list for security and update notifications. Its lifecycle page recommends the latest maintenance release of the newest major branch an operator can use. The next embargoed disclosure is expected two weeks after the 32.0 release and will describe three medium or high severity vulnerabilities already fixed in 30.0.
What to watch
- First classified case: An advisory identifying an easily discoverable flaw, its affected versions and the basis for the fast release.
- Three point releases: Corresponding fixes for 30.x, 31.x and 32.x, or an updated maintenance boundary if a new major version arrives.
- Advisory detail: Clear distinctions among miners, merchants, custodians and home nodes when their actual exposure differs.
- Operator adoption: Dated version measurements with an explicit sample, alongside disclosures from services that run private nodes.
- Pending old cases: The three medium or high severity fixes from 30.0 that version 32.0’s notes say will be explained after the usual delay.
FAQ
What changed in Bitcoin Core’s security policy in October 2026?
A change merged on October 22 lets maintainers disclose readily discovered vulnerabilities with a security advisory when they ship fixes for each maintained major version. The normal severity-based embargo remains for other cases.
Does the new policy mean Bitcoin Core has a new bug today?
No specific vulnerability was announced with the policy revision. It changes how a confirmed future report can be classified and disclosed.
What counts as an easily discoverable Bitcoin Core flaw?
The policy points to issues findable with minimal effort, including a simple AI prompt. The criterion is not limited to AI, and maintainers make the decision during triage rather than applying a published numerical test.
How many Bitcoin Core versions receive the faster fix?
Bitcoin Core maintains its latest three major versions. Following the 32.0 release, the relevant branches are 30.x, 31.x and 32.x; 29.x and older are outside the maintenance window.
Will every Bitcoin Core vulnerability be disclosed immediately?
No. Low severity issues ordinarily appear two weeks after a major version with the fix. Medium and high severity details may wait until two weeks after the last affected branch reaches end of life; critical flaws require an individual response.
Why can a public advisory create risk?
It helps operators identify affected software, but it can give attackers clues while some nodes still run old versions. Bitcoin developer Antoine Riard warned that a generic alert might prompt unnecessary rushed upgrades among users with different exposure.
Are AI-generated vulnerability reports all real?
No. The Bitcoin Red Team’s 4,962 potential findings spanned 390 projects and required reproduction and review. Those figures are not a count of confirmed Bitcoin Core flaws.
When will we know whether operators can update in time?
The first advisory under the fast route will show the release dates, affected branches and instructions. Public node measurements can show some uptake, but private deployments may be missing. This is educational analysis, not investment advice.
Disclaimer: This article is for information and educational purposes only and does not constitute financial or investment advice. Figures reflect regulatory filings and reporting available at the time of writing and change with each disclosure. Nothing here is a recommendation to buy, sell, or hold any security or asset. Always do your own research. Information is accurate as of October 24, 2026.