Articles & Essays

The CVE Factory We Built On Purpose

960+ vulnerabilities in one Patch Tuesday isn't a bad month for Microsoft - it's the predictable output of a discovery machine the whole industry built, colliding with a patch process still run on human time.

Microsoft's September 2026 Patch Tuesday addressed more than 960 vulnerabilities in a single release - the largest single-month patch batch in the company's history. CISA issued federal remediation deadlines in the same window: critical RouterOS flaws by September 13, a ScreenConnect code-execution vulnerability by September 14, an Artifactory repository-exposure issue by September 25. A separate GitLab path-traversal vulnerability, CVE-2026-85706, allowing unauthenticated file reads, was disclosed in the same stretch of days.

None of this is Microsoft failing at security. A 960-CVE month is, in part, evidence of the opposite: more automated fuzzing, more bug-bounty coverage, more static analysis running against more of the codebase than at any point before. Security teams industry-wide have spent the last several years professionalizing vulnerability discovery specifically so flaws like these get found by researchers instead of attackers. That investment is working. Part of why the count is climbing is that the search got better.

What makes this particular month distinct isn't any single CVE - it's the stacking of federal deadlines against one disclosure window. Three separate CISA remediation clocks, plus an independently disclosed GitLab flaw, all landing inside the same few days as the largest Patch Tuesday on record. That specific collision is a news story, and it fades the way every patch-cycle story fades: once September's advisories clear the queue, this exact combination of dates and CVE counts stops being interesting. What doesn't fade is the shape underneath it.

The take running through the trade coverage - Security Boulevard, DEV Community, This Week in Security - is straightforward: patch now. 960+ vulnerabilities and three federal deadlines inside one week is a genuine, urgent workload, and anyone running Windows infrastructure or the affected products needs to move fast. That's correct, and nothing that follows is an argument against patching quickly. The deadlines are real and the exposure is real.

But "patch now" treats the count as a weather event - something that happened to the industry this month - rather than the output of a machine the industry built on purpose. The last several years went into industrializing vulnerability discovery: fuzzing at scale, mandatory bug bounties, static analysis wired into CI, dedicated red teams. That machine now finds vulnerabilities faster than most organizations' patch cycles can absorb them. 960 disclosures in a month isn't one company having a bad month. It's the predictable output of a discovery pipeline running at industrial scale, colliding with a patching process still organized around monthly human review. The gap between disclosed and actually patched in production is a structural lag, and it's the thing actually worth writing about - not which CVE to fix first.

I run my own inference stack and ship LLypses as software people install on their own machines, which puts me on both sides of this gap at once - the vendor who has to patch fast, and the operator who has to apply patches fast, with no IT department between me and either job.

That's the part that generalizes past this one month. The discovery side of security has scaled with automation - fuzzers don't get tired, static analyzers don't take weekends. The patching side is still bottlenecked by human review, testing, and deployment windows, especially for anyone without a dedicated security team. That asymmetry doesn't show up as a single breach. It shows up as a permanent, growing backlog every organization is quietly carrying, and it's the backlog - not any individual CVE - that eventually gets exploited. If you ship software, self-host anything, or run infrastructure with fewer hands than Microsoft has, the CVE-factory problem is already yours. The only question is whether your patch cadence is a number you actually know, or a guess.

Patch this week's list. That part was never in question. But the number worth remembering after the advisories clear isn't 960 - it's how many days it actually takes you, personally, to close a critical vulnerability once it's disclosed. Most people running their own stack don't know that number. It's worth finding out before the next 960-CVE month, because there will be one.