Skip to content
Blockchain Posts

protocol

Bitcoin Core adds 'easy-to-find' bug track as LLMs lower the attack bar

Pull request #1281, merged October 22, splits security disclosures: bugs an attacker can easily rediscover now ship fixes to every supported release ASAP with details attached.

by 4 min read
protocolbitcoinsecuritybitcoin-coretooling

Bitcoin Core maintainers merged a change to the project's security disclosure policy on October 22, 2026, carving out a new "easy-to-find" category for vulnerabilities that LLMs can rediscover from source. The change was authored by Chaincode Labs developer Antoine Poinsot (darosior) and merged by fanquake as PR #1281 on bitcoin-core/bitcoincore.org. CoinDesk broke the news this morning.

What the policy change does

Historically, Bitcoin Core graded vulnerabilities by severity and held them under embargo:

- Low severity    : disclosed ~2 weeks after the next MAJOR release
- Medium / high   : embargo until ~2 weeks after the last affected
                    version reaches end of life (can run near a year)

Under the merged PR, triage can additionally flag any bug as easy-to-find. For a bug on that track:

  • The fix is backported to every currently supported release.
  • A point release is cut as soon as possible — not held for the next major.
  • The security advisory published alongside the release includes details.

Maintainers noted the trade-off: fast point releases get less bake time than scheduled ones. Poinsot's rationale in the PR: "We recently experienced an increase in the number of reports for security vulnerabilities that can be easily (re-)discovered. This is largely due to LLMs drastically reducing the bar to find certain classes of issues or identify covert fixes."

A longstanding Core security researcher, Antoine Riard, pushed to keep the option of shipping a quiet fix without any advisory. Poinsot rejected it: "Alerting users of a security vulnerability without any details could create more risk unnecessarily." The merged text keeps the advisory.

Why the change now

CoinDesk cites three recent incidents that pushed the policy:

  • A BTCPay Server flaw, reported privately by the Bitcoin Red Team, was then exploited in production and drained Lightning nodes on live merchant servers before fixes propagated.
  • Core Lightning maintainers told operators to disconnect peers after AI-generated vulnerability reports — initially treated as noise — turned out to describe a real bug.
  • A Coldcard hardware-wallet firmware flaw dormant since 2021 was exploited on July 30, draining 594 BTC in 25 minutes; CoinDesk reports losses near $114M across four sweeps. That bug did not require AI to find, but Coldcard credited AI tooling with helping it catch more issues while shipping the fix.

The Bitcoin Red Team's own work scanned 390 projects with AI models and logged 4,962 findings, 85 of them critical, per the report cited in the PR discussion.

Impact

The practical consequence is that users on long-tail versions of Bitcoin Core now get patched sooner for a class of issues that will keep growing as LLM-assisted code review becomes routine. Node operators who track master or the latest release get no new obligation; operators on older but still-supported branches now have point releases arrive on a tighter clock.

The policy is Core-only. Downstream projects (BTCPay, Core Lightning, LND, forks) each run their own disclosure process. The BTCPay and Core Lightning episodes are the proximate case for them to follow suit.

What to watch

  1. The first point release under the new category. The commit changed policy, not any live advisory. The real test is the first bug that gets flagged and shipped — how fast, how detailed the advisory is, and whether downstream reorgs around it.
  2. Downstream alignment. Core Lightning and LND release managers will come under pressure to adopt a parallel track; the Lightning incident is a template.
  3. Advisory content. The embedded reasoning for keeping details in the advisory is that the bug is already findable from source. If an advisory ever omits a crucial detail that an LLM could still surface, the policy debate reopens.
  4. AI tooling disclosure. Red Team-style programs are now a visible part of Bitcoin security. Expect more projects to publish scan-report summaries the way the Bitcoin Red Team did for its 390-project pass.

Context

The policy shift fits a pattern that's hardened over the last two quarters: fix latency, not detection, has become the bottleneck in protocol security. Red Team-style AI scans surface candidates faster than coordinated disclosure processes can ship them. PR #1281 is Core's answer to that gap for a specific sub-class of bugs; it does not pretend to be an answer for everything.

Sources:

Related stories