October 2026, the Witching Month of Patches

Trick or treat, update your browser

If your laptop felt clingy this week, you were not imagining it. On Monday, October 26, CISA added two PHP flaws — the "PHP2Shell" pair — to its Known Exploited Vulnerabilities catalog. On Tuesday, Firefox 159 shipped with a security advisory containing 167 CVEs. On Wednesday, WordPress 7.1.4 addressed 22 vulnerabilities, its second security release of the month. That same week, Google published a Chrome 156 update containing 52 security fixes. Earlier in October, independent tallies of Microsoft's Patch Tuesday exceeded 1,400 vulnerabilities, and Oracle's quarterly update delivered 1,295 new security patches.

For anyone outside security, the headline writes itself: software is falling apart. My hypothesis is the opposite — or, at least, more boring. Many of these monsters were already living in the house. What changed in 2026 is that we got much better flashlights.

That is a hypothesis, not a conclusion. So I collected historical numbers and accounts from the teams shipping the fixes to see where it holds and where it breaks.

How big is the haunting?

First, an apples-to-apples comparison using official quarterly metrics. These are published CVE records, not the dates on which flaws entered the codebase.

Source: CVE Program — published CVE records by quarter. All bars cover January through September, not full calendar years.

For context, the same official source lists full-year totals of 28,961 for 2023, 40,077 for 2024, and 48,244 for 2025. By September 30, the 2026 count had already passed all three. The third quarter of 2026 alone accounted for 36,962 published records, compared with 11,738 in Q3 2025 — about 3.1 times as many.

The growth did not start in 2026, but 2026 is a different animal. In June, FIRST's forecasting team revised its projection to approximately 66,000 CVEs for the entire year. The published total exceeded that forecast by the end of September. That does not mean forecasting failed in a simple sense: the team had explicitly discussed unusually wide uncertainty ranges and the possibility of AI-driven discovery exceeding expectations.

Now narrow the lens to October. Not every vendor uses the same unit, so these examples should not be added together.

Sources by row: Oracle's October 2025 and October 2026 advisories; WordPress's 7.1.3 and 7.1.4 release notes; BleepingComputer's independently compiled Microsoft October 2025 and October 2026 counts. The Microsoft numbers are not official standardized totals; the MSRC Update Guide is the canonical source for a future like-for-like recount.

Even that WordPress contrast is sensitive to the calendar: its 6.8.3 security release landed on September 30, 2025, just one day before the comparison window. A monthly tally tells us when fixes shipped, not how secure the project was the day before.

So yes, October 2026 looks exceptional across several major release programs. But the numbers alone cannot tell us what kind of exception it is.

Where the ghosts come from

The strongest evidence for the flashlight hypothesis does not come from CVE totals. It comes from maintainers describing their own workloads.

Mozilla was fixing roughly 20 to 30 security bugs per month in Firefox throughout 2025. In April 2026 that number was 423. The team attributed 271 of those fixes to bugs identified with Anthropic's Claude Mythos Preview. In a detailed Mozilla Hacks post, Firefox engineers explained how they built an agentic discovery pipeline on top of their existing fuzzing infrastructure.

Their account is more interesting than a simple "AI found the bugs" headline. The gains came from better models and better engineering: reproducible test cases, ephemeral virtual machines, deduplication, triage, and integration with Firefox's existing fix-and-release workflow. The key point is not merely that the models were stronger; it is that the surrounding harness and validation systems made their findings operationally useful.

On October 29, Firefox's Bobby Holley reported that the team had shipped more than seven times as many security fixes as during the corresponding period of 2025, using early access to frontier models from Anthropic and OpenAI. The Firefox 159 advisory also names OpenAI researchers and OpenAI Codex Security among the reporters.

WordPress tells the same story from the inbox side. Its HackerOne program had received 20 to 30 reports per month for roughly a decade. In July 2026 it received 450; in August, 773. According to Rudy Faile's October 29 report, the project had received more than 3,000 reports in 2026 — more than the previous twelve years combined, excluding spam and reports marked not applicable.

The team has responded with substantial changes, but it would be misleading to say the backlog has simply disappeared. WordPress reports seven Core security releases since mid-July, closing more than 50 critical or high-severity issues, with fixes backported to older supported branches as far back as 4.7. It also automated approximately 73% of the 109 steps in its security-release process. That is an operational response to the increased volume, not proof that maintainers can absorb every report without delay.

GitHub saw the wave early. In May 2026, its Advisory Database published 1,560 reviewed advisories, more than five times its typical monthly output. Private vulnerability reports went from about 550 per week in January to more than 3,000 per week for much of May, while GitHub's CVE Numbering Authority received nearly 4,000 CVE requests in May alone. Review times grew from days to weeks for a meaningful share of submissions.

The bottleneck did not disappear when discovery got cheaper; it shifted toward validating, deduplicating, coordinating, fixing, and publishing the findings.

Independent analysis from Epoch AI likewise found a dramatic spike in high- and critical-severity CVE disclosures among major organizations in mid-2026. The timing is consistent with the emergence of more capable security research models, but timing alone is not proof of causation.

This matters for the thesis. We have directly documented examples of old, previously undiscovered bugs being found faster. We do not have sufficient data to say that almost all 2026 vulnerabilities were old, or that newly written code has become better or worse. A CVE published in October 2026 can describe a bug that shipped years earlier; publication date is not introduction date.

Part of the monster is the measuring tape

Before celebrating, there is an uncomfortable confound: the way we count changed too.

Mozilla's Firefox 159 advisory notes that internally found memory-safety bugs are now disclosed as individual CVEs instead of being bundled under a single umbrella identifier. That makes the headline number bigger even when the underlying engineering work is similar.

The broader CVE system is changing as well. The CVE Program's metrics page shows that the number of active CVE Numbering Authorities increased from 263 at the end of 2022 to 563 by the end of Q3 2026. Meanwhile, the share of published records issued directly by CNAs rose from 74% in 2022 to 95% by Q3 2026. More publishers mean more records, regardless of whether the software itself got any less safe.

Even Microsoft's October Patch Tuesday demonstrates how counting methodology matters. Different analysts produced different totals because they may include or exclude previously disclosed issues, third-party component CVEs, reissued updates, or other categories. For a consistent multi-year comparison, we would need to reprocess the MSRC data under one explicit set of inclusion rules.

The infrastructure is under strain. In September, CISA published a "Quality Era" framework for the CVE Program, reflecting concern about maintaining useful records as disclosure volume grows. GitHub has similarly described the importance of high-quality version ranges and reproducible evidence when every curation bottleneck compounds downstream.

The curve is real. But it is a measure of published records, not a direct readout of how unsafe today's software is.

The real test: are more of these actually being exploited?

If growing disclosure volumes reflected a proportionate growth in actual attacks, we would expect stronger supporting evidence from exploitation data. One useful — though incomplete — source is CISA's Known Exploited Vulnerabilities (KEV) catalog, which includes vulnerabilities for which CISA has evidence of exploitation in the wild.

For this article, I counted entries by their dateAdded field in a catalog snapshot dated October 30, 2026: 187 in 2023, 186 in 2024, 245 in 2025, and 246 from January to September 2026.

Source: aggregated data from the official CISA KEV dataset, snapshot dated October 30, 2026. A KEV dateAdded is the date CISA added an entry to the catalog, not necessarily the date the vulnerability was published or first exploited.

This comparison cuts both ways. The number of published CVEs has accelerated much faster than the number of additions to the KEV catalog. But we cannot divide these two numbers and call the result the percentage of new vulnerabilities being exploited. The KEV additions may concern CVEs from years earlier; the published CVEs belong to another population and have had different amounts of time to be exploited and investigated.

To measure an exploitation rate, we would have to follow each cohort of CVEs published in a given period and check which later received evidence of exploitation, accounting for the delay in observing and recording attacks. KEV is useful, but it does not capture every exploited vulnerability or the number of attacks against each one.

FIRST's June analysis offers a more carefully bounded observation: while disclosure volumes were growing sharply, its actionable-risk overlay — based on KEV membership and an EPSS probability above 10% — remained relatively stable during the first half of 2026. That is not proof that cyberattacks stopped growing; it is a useful warning against treating all published CVEs as equally urgent.

Nor do the absolute KEV numbers justify complacency. In the same October 30 snapshot, the count for January through October 2026 was 282, compared with 214 in the equivalent 2025 period — about a 32% increase. And October supplied a real-world counterexample: AWS Threat Intelligence reported PHP2Shell exploitation attempts beginning October 17, four days before PHP published emergency fixes on October 21.

There is a Halloween bonus, too. Some vulnerabilities added to KEV in 2026 carry identifiers from much earlier years. The monsters are not always new: some are zombies that never quite stayed buried.

The monster that actually grew: the patch gap

There is a more concrete emerging danger in this data: the time between a fix becoming visible and reaching users. This is the patch gap. The gap is not new, and it does not end merely when a release is announced; users and organizations still have to deploy the update.

The same models that find bugs can examine patches. Anthropic's Frontier Red Team reported that Mythos Preview produced a working exploit for a Firefox vulnerability within an hour of its fix landing in public source code, when the corresponding release was still 18 days away.

On October 29, Epoch AI published a direct experimental study using GLM 5.3, an open-weight model. It reported successful lab attacks against six Firefox releases between September 17 and October 26 by reasoning from public fixes. The marginal attack cost was approximately $1,000 per Firefox version, at API prices, after the researchers had built their harness. The full research effort cost over $100,000. The attacks also relied on a separate, previously unpublished vulnerability, and the paper does not establish that the same method succeeds universally against all browsers or configurations.

Vendors are responding. Mozilla says Firefox has accelerated shipping so that new builds reach users weekly, while also holding certain regression tests back until fixes ship, scanning new commits for bugs, and exploring ways to stagger fixes across separate sandbox boundaries. A Mozilla Support post from August described the earlier move to a two-week major-release cycle; the October security update describes a faster current build cadence. WordPress's automation of its security-release workflow is another response to the pressure to move faster.

Here, faster discovery is a double-edged sword. It helps defenders retire vulnerabilities sooner — but it can also make partially disclosed fixes easier to weaponize before the repaired software is installed.

Scorecard

So, haunted or not?

My reading is that the perception of a software security apocalypse is, at least partly, a measurement problem. We are exposing defects that spent years in the dark, expanding the number of organizations that report them, and forcing maintainers to rethink how they validate and ship fixes. That can be good news — provided disclosure is matched by effective remediation.

But this is not permission to relax. A fix published upstream is not the same as a fix installed on a vulnerable system. And once a public patch identifies a useful weakness, an attacker may now have tools capable of turning that information into a working exploit far faster than before.

The practical advice is unglamorous. Enable automatic updates where appropriate; for systems you manage, combine CISA KEV, EPSS, exposure, asset criticality, and vendor guidance instead of prioritizing by raw CVE count alone. Track whether updates actually reach production, not merely whether a ticket was filed.

Better flashlights are finally showing us the monsters that were already in the house. The scary part is not how many we found this October. It is how long we leave the door open after we know where they are.