Apple, AWS and Google Are Finding 6x More Critical Bugs than they did for four years.

For four years, across 21 major software companies including Apple, AWS, Microsoft and Google, reported critical vulnerabilities never cleared 100 per month.

Since spring 2026 they have been over 600. High-severity findings have passed 2,000.

Before anyone reaches for a conclusion, note the verb in the headline, because it is the whole argument. These companies are finding more critical bugs. That is not the same claim as their software having become six times worse, and the difference decides what you should do about it.

From a16z's Charts of the Week, plotting Epoch AI data. Vendors include Adobe, AMD, Apache, Apple, AWS, Cisco, GitHub, Google, IBM, Intel, Linux, Microsoft, Mozilla, NVIDIA, OpenSSL, Oracle, Qualcomm, Red Hat, Samsung, SAP and VMware.

Software did not get six times worse in one spring

Codebases at Apple and Microsoft are decades old. Nothing happened in March 2026 that could make four years of accumulated code six times more vulnerable in a quarter.

What happened is that finding bugs got dramatically cheaper. The most credible reading of the chart, and the one several analysts landed on independently, is that the vulnerabilities were already in there and AI made them findable at a speed no human security team could match.

Anthropic's Project Glasswing is the clearest worked example. It reportedly surfaced more than 10,000 high or critical severity weaknesses, many of which were never disclosed individually. One programme, one spring, and a number large enough to move an industry-wide chart on its own.

That detail matters for how much weight the 6x can carry. If a handful of large automated discovery efforts account for a meaningful share of the jump, then the curve is partly measuring how many people pointed AI at old code this year, which is a different and less alarming thing than an industry-wide collapse in software quality.

Why that is not the reassurance it sounds like

Here is the uncomfortable half. If the bugs were always there, then for four years every one of those companies was shipping software with roughly 600 critical vulnerabilities a month in it, and simply had no economical way to find them.

The 100-a-month ceiling was never a measure of how secure the software was. It was a measure of how much security review anyone could afford. The ceiling was a budget, not a property of the code.

And the capability that lifted it is available to both sides. Kevin Mandia, quoted in the same a16z research, describes what changes when the finder is a machine:

"When you have an AI-based attack, it'll find logic flaws rather than code flaws in custom applications. It'll exhaust all routes all the time."

Both halves of that are worth sitting with. Logic flaws are the class that static scanners miss, because nothing is syntactically wrong: the code does exactly what it says, and what it says is wrong. And exhausting all routes is precisely the thing human attackers never did, because they got bored and went after easier targets.

Obscurity was load-bearing and nobody put it on the architecture diagram. Most applications were safe because attacking them was not worth a person's week. That calculation has changed.

The bill arrives for the thing you shipped faster

Aaron Levie named the three categories of new work this creates, and the framing is the useful part:

Three distinct problems that get collapsed into one budget line and should not be.

Vibe-coded issues are the ones you introduced by shipping faster. If your engineers now merge four times the code with the same review headcount, the review-per-line ratio fell by 75% and nobody logged that as a decision.

Agentic attacks are Mandia's category: tireless, exhaustive, logic-flaw-hunting. They do not care that your app is small.

Accidental agent damage is the one almost nobody has a plan for, and it is not an attack at all. It is your own agent, with real credentials, doing something destructive because the guardrail was a sentence in a prompt rather than a permission in a system. That is the distinction behind enforcing limits in the harness instead of asking the model nicely.

What this actually asks of your company

Do not read this as a reason to slow down shipping. That is the wrong lesson and most companies cannot afford it anyway.

Read it as a ratio that moved. Three questions:

How much more code are you merging than a year ago, and did review capacity move with it? If output tripled and the security team did not change size, you have already made a decision about risk tolerance. Make it deliberately.

Are you using the same capability defensively? The asymmetry in that chart only hurts you if the attackers are the only ones running AI against your codebase. The same tooling that produced those findings is commercially available.

What can your agents do if they are wrong? Not what will they do. What can they do. Levie's third category is the one that bypasses your perimeter entirely, because it is already inside it and you issued the credentials.

The four-year ceiling was never protecting anyone. It was just the point where looking got too expensive. Looking is cheap now, and that is true for everybody.