The worst flaw of the month had been sitting in the same code since before the iPhone existed. What changed was not the code. It was who was reading it.

October 2026 will be remembered as the month the patch treadmill broke.

In four weeks the industry shipped a run of maximum-severity flaws — three of them scored a perfect 10.0 — plus a Microsoft update containing more than 1,400 fixes and an emergency patch to PHP — the runtime underneath roughly 70 percent of the web. Governments took websites offline. The US National Security Agency told organizations to disconnect systems they could not patch. Japan's prime minister posted on social media asking people to check whether their websites ran on PHP.

None of that is the interesting part.

The interesting part is that two of the month's highest-profile bugs — one in code that had been public for over a decade, and one actively exploited in the wild on Windows — were found with the assistance of frontier AI models. Not scanned. Not fuzzed. Found, understood, and turned into working exploits.

That is a change in the economics of vulnerability discovery, and it lands directly on anyone responsible for keeping a website running.

What October actually delivered

Here is the month, in order. Every entry below is a real advisory, not a theme.

October 8 — Bricksforge, CVSS 10.0. An unauthenticated arbitrary file upload in the Bricksforge plugin for WordPress, tracked as CVE-2026-85097. The plugin checked a file's MIME type at upload, then trusted the client-supplied url field on form submission. Attackers chained that into PHP execution in four steps. Patchstack's telemetry first observed exploitation on October 7 at 21:47 UTC — the day before the advisory was published. Fixed in 3.1.8.10.

October 12 — GitLab, CVSS 10.0. CVE-2026-97229, an integer overflow in the CI/CD regular expression compiler. GitLab scored it 10.0 on the basis that the final trigger is unauthenticated, and Rapid7 reproduced code execution against 19.4.1. But Rapid7 also noted the step before the trigger: an attacker first needs a way to plant a malicious .gitlab-ci.yml and a UTF-8 repository path into a public project. On an instance where anyone can self-register and create projects, that step costs an ordinary account and nothing else. Where registration is locked down, it is a real barrier.

October 13 — Microsoft's largest Patch Tuesday on record. 1,413 CVEs, of which 75 are rated Critical, plus three zero-days: one under active exploitation and two publicly disclosed before the fix. The exploited one, CVE-2026-96951, is a Windows Shell security feature bypass rated 8.8 that defeats Mark of the Web — the tag Windows applies to files downloaded from the internet, and the thing SmartScreen, Office Protected View, and the Attachment Manager prompt all rely on. Microsoft credited the reporting researchers, including Benoit Sevens, using Claude with Anthropic, alongside two Fujitsu researchers and an independent researcher.

October 16 — Plex2Shell goes public. A researcher published a write-up and proof-of-concept for four chained Plex Media Server flaws: CVE-2026-96652, CVE-2026-96654, CVE-2026-96655 and CVE-2026-96656. The entry point is a server-side request forgery in /player/timeline that lets an unauthenticated attacker make the Plex server POST to arbitrary destinations, including its own internal APIs. Weaponized within a day. CISA added all four to its catalog of known exploited vulnerabilities on October 20.

October 21 — PHP itself. Two vulnerabilities in PHP core, CVE-2026-109618 and CVE-2026-109619, both rated 9.2 under CVSS v4.0, allowing unauthenticated remote code execution and remote disclosure of server process memory.

October 21 — GitLab again, CVSS 10.0. CVE-2026-110264, a second integer overflow in the regex compiler, affecting every self-managed GitLab version from 7.0 onward. GitLab's wording is that "under certain conditions" an unauthenticated user could execute code, and it has not published a technical description of what those conditions are. No workaround was named. GitLab.com was already running patched versions, so this was a self-managed problem. If you took the October 12 fix, you still needed this one.

The number that should bother you more than the severity scores

CISA added 28 vulnerabilities to its Known Exploited Vulnerabilities catalog during October, as of the October 26 update.

Six of those 28 were not new at all. Five date from between 2015 and 2023 — BIND, Apache Struts, Strapi, ONLYOFFICE, ProFTPD — added in a single batch on October 8. A sixth, a Fortinet path traversal, carries a 2025 CVE.

Read that again, because it inverts the usual framing. Attackers were not only racing to exploit last week's disclosure. They were successfully hitting decade-old bugs that a great many organizations had long since stopped thinking about. The KEV catalog is not a list of recent news. It is a list of things that are being exploited right now, and a meaningful share of it is old enough to have been patched several times over.

That is the backdrop for everything AI-driven discovery is about to do.

What made October different: the discovery side changed

The PHP flaws are the clearest example, and the timeline matters.

Wiz Research found the first of them on August 19, 2026, using a combination of their Wiz Atlas tooling and two frontier models — Gemini 4 Argon and GPT-5.6 Sol. Within two days they had confirmed unauthenticated remote code execution against Drupal and against WordPress. They reported to the PHP security team on August 24. PHP acknowledged on September 21 and began building a coordinated fix. Patches and public disclosure landed together on October 21.

Two months from discovery to industry-wide emergency, for bugs in a runtime that the entire security industry had spent twenty years looking at.

Wiz's own conclusion is worth quoting rather than paraphrasing:

The vulnerable code had been present for more than a decade. Turning these flaws into working exploits required chaining multiple bugs and accounting for how PHP allocates and reuses memory across requests. […] Pre-AI, this manual work would be difficult to implement and even harder to scale.

And then:

It marks an AI inflection point. The vulnerable code had been there for more than a decade — what AI changed was the ability to understand the weaknesses and turn them into a working exploit.

Note the precise wording. AI did not merely locate a bug. It did the part that used to be the real barrier: adapting an exploit across PHP versions, configurations, and memory layouts, iterating on failures, and getting from "theoretically corruptible" to "runs code on this specific deployment." That work used to require a specialist and weeks. It is now something a model can grind through.

The same theme shows up in Microsoft's October release. Computer Weekly put much of the record volume down to AI-assisted vulnerability discovery — an attribution worth reading as informed opinion rather than a controlled measurement, since CVE volume also depends on reporting practices and vendor disclosure processes. And the exploited Windows zero-day carries a credit line naming a researcher "using Claude with Anthropic" — a credit format that barely existed two years ago.

This is not only a defensive story. Google's Threat Intelligence Group reported in May 2026 that it had, for the first time, identified a threat actor using a zero-day exploit it believed was developed with AI — an assessment Google based on the exploit's characteristics, not on tracing which model produced it — a two-factor authentication bypass in a popular open-source system administration tool. Their analysts made a point that is useful for defenders: the flaw was not memory corruption or bad input sanitization. It was a semantic logic error where a developer hardcoded a trust assumption. Fuzzers and static analysis tools are built to find sinks and crashes. They are weak exactly where a reasoning model is strong — reading intent, spotting the contradiction between the stated rule and the exception someone carved into it.

Why this shifts the defender's problem, not the attacker's

It would be easy to read all this as "attackers get better, nothing to be done." That is the wrong conclusion. What actually changed is where the bottleneck sits.

For twenty years, finding a serious bug was the expensive part. Now finding — and weaponizing — is getting cheaper every quarter. The expensive part has moved to knowing what you are running.

Three things from October make that concrete.

The interesting flaws were not in things you choose to install. The PHP vulnerabilities are application-agnostic. Wiz demonstrated code execution against stock WordPress, Drupal, and Joomla containers, but their writeup is explicit that the flaws live in the engine: "even a simple 'Hello World' application running on an affected PHP version can be vulnerable." The question "do I use that plugin?" cannot help you here, because the answer is about your runtime, not your feature list.

The window between disclosure and exploitation is now measured in hours. Patchstack's mitigation rule for Bricksforge was live before the first attack arrived — and the first attack still arrived the day before publication, meaning someone was already working on it before anyone published a warning. Plex2Shell went from proof-of-concept to observed exploitation in a day.

Patching faster does not solve old bugs. Six of October's 28 actively exploited entries predate 2026. A team that responds brilliantly to this week's advisory is still exposed by something from 2021 that nobody remembered was running.

What most site owners assume decides their exposure What actually decided it in October
Which plugins and themes are installed Which runtime version sits underneath them
Whether the vendor published a patch Whether anyone knows the affected component is even present
How fast the team reacts to this week's news Whether the same team has an accurate inventory at all
Whether a WAF is in front Whether the thing behind the WAF can be identified and fixed

What AI does not do for you

Being honest about the limits matters more than the enthusiasm.

An AI model finding bugs in a codebase is not the same as an AI model protecting your site. The models that found the PHP flaws were pointed at source code by researchers who knew what to ask. Pointed at nothing in particular, they will produce nothing in particular.

The useful parallel for a small business is narrower and more practical: automated reasoning is now genuinely good at the part humans are worst at — patiently enumerating a large, boring, fast-changing surface and noticing what does not fit. That is exactly the shape of the problem a website owner has. You do not have a source-code review problem. You have a "what is actually exposed on my domain right now" problem, and it changes every time someone adds a form, installs a plugin, spins up a dashboard, or migrates a host.

The October lesson is not "buy an AI." It is that one part of the discovery pipeline got cheaper, and inventory is now the constraint on your side.

And a fair caveat on the whole argument: one month cannot prove a permanent shift. The PHP findings show what a well-resourced team with frontier models and test infrastructure can now achieve; they do not show that every serious bug will be found and weaponized on that timetable. What they do establish is direction. Plan for the direction, not for the calendar. Whatever closes that gap for you — tooling, a provider, or a habit — is the control that matters.

What to do this month

This week

  • If you run Bricksforge, update it. The unauthenticated upload path (CVE-2026-85097) is being actively exploited and needs no credentials.
  • If you self-host GitLab, get to a release that covers CVE-2026-110264, not just the October 12 fix. Both are 10.0; the second one had no workaround.
  • If you self-host Plex Media Server and it is reachable from the internet, update it. If it does not need to be internet-facing, that decision is worth more than the patch.
  • PHP: this one deserves its own entry, because the action depends on who manages your runtime. See our full breakdown of the PHP flaws for the version list, the difference between mod_php and PHP-FPM, and what to ask your host.

This month

  • Make a list of everything answering on your domain — including the things nobody remembers installing. Subdomains, admin panels, old staging environments, that media server, that self-hosted tool someone set up for a project in 2023.
  • Compare that list against the CISA KEV catalog. It is public and free, and it answers a different question from a CVSS score: what is known to be exploited rather than what is theoretically serious. It is not a complete picture of active attacks, and it is no substitute for vendor advisories.
  • Accept that some of what you find should be switched off rather than patched.

Ongoing

  • Treat "what do we expose" as a standing question with a recurring answer, not a one-time audit.
  • When a maximum-severity flaw lands in a component you did not know you had, the failure was not the patching. It was the inventory.

Key numbers

  • 1,413 — Microsoft CVEs fixed in the October 13 Patch Tuesday, 75 of them Critical
  • 3 — maximum-severity 10.0 flaws shipped in October: Bricksforge CVE-2026-85097 and GitLab CVE-2026-97229 and CVE-2026-110264
  • 9.2 — CVSS v4.0 score for both PHP core flaws, CVE-2026-109618 and CVE-2026-109619
  • 70% — share of websites running PHP
  • 28 — CISA KEV additions during October, as of October 26
  • 6 — of those 28, the number that predate 2026
  • 1 day — time from Plex2Shell proof-of-concept to observed exploitation
  • 2 months — Wiz's discovery of the PHP flaws to worldwide emergency disclosure

The takeaway

On the evidence of October, the reasonable assumption is that this is a trend rather than a one-off bad month. That is a judgement, not a forecast — but it is the safer planning assumption.

The bugs that hurt this month were not the newest or the most exotic. One had been sitting in the same code for longer than most companies have existed. Several were years old and already patched on paper. What AI changed is that the gap between "someone could exploit that" and "someone has a working exploit" collapsed — and it collapsed for exactly the class of unglamorous, deep, forgotten code that never gets attention.

You cannot out-patch that. You can, however, out-know it. The organizations that came through October badly were not the ones that patched slowly. They were the ones that could not have told you what they were running.

Start with an accurate picture of your own surface. Everything else is downstream of that.

Related reading:

Not sure what your site is exposing? Run a free security scan — 40+ automated checks on the public signals that matter, instant results, no commitment.

Source Notes