Zero Days Are Now Every Days: Here's What Google's 2026 Threat Report Actually Means

Software vulnerabilities just became the #1 way hackers break into cloud environments. Not phishing. Not weak passwords. Your unpatched software. And the window to fix it? 48 hours. AI just made that worse on both ends.

There’s a stat buried in Google’s 2026 Cloud Threat Horizons Report that should genuinely change how you think about vulnerability management. In H2 2025, software vulnerability exploitation became the primary cloud attack vector for the first time. Ever. It now accounts for 44.5% of initial access events, overtaking weak credentials, which fell from 47.1% to 27.2% in the same period.

That’s a seismic shift. But it’s the why behind it that’s really interesting.

Hackers Didn’t Get Smarter. You Got Better (Accidentally)

Here’s the contrarian take: this isn’t purely bad news. It’s actually evidence that years of beating the credential hygiene drum worked.

Cloud hyperscalers have been quietly hardening their default configurations. MFA got rolled out everywhere. Password policies tightened. The easy wins (open S3 buckets, default admin credentials, absent MFA) started drying up. So attackers, being the rational opportunists they are, moved up the value chain. They stopped going through unlocked doors and started picking locks instead.

The “cheap” entry points got expensive. So they switched to software.

In other words: the security industry collectively improved credential security to the point where attackers were pushed toward a harder problem. That’s progress. The uncomfortable part is that the harder problem, unpatched software in your own environment, is now entirely your problem. Google can harden Google’s infrastructure. Nobody else can patch your applications for you.

The Stat That Should Actually Scare You: RCE Up Nearly 5x

Within the broader software exploitation category, Remote Code Execution (RCE) attacks grew from 2.9% to 13.6% between H1 and H2 2025. That’s nearly a five-fold increase in twelve months.

RCE is the nastiest end of the software exploitation spectrum. It’s not just “attacker read something they shouldn’t.” It’s “attacker ran arbitrary code on your infrastructure.” They’re not picking locks. They’re dissolving the door.

And they’re doing it using known CVEs. Not sophisticated zero-days requiring nation-state resources and months of research. Publicly disclosed, catalogued, NVD-listed vulnerabilities in applications running on Google Cloud Engine and Google Kubernetes Engine. The kind of vulnerabilities that have patches available. The kind that your team probably knows about.

Which brings us to the actual problem.

Zero Days Are Now Every Days

The term “zero day” used to mean something specific: a vulnerability that’s unknown, unpublished, and unpatched. A secret weapon that only the attacker knows about. The implication was always that known vulnerabilities (the ones with CVEs and published patches) were manageable. You had time.

That framing is dead.

After CVE-2025-55182 (dubbed React2Shell, a critical flaw in React Server Components) was publicly disclosed, Google observed mass exploitation beginning within approximately 48 hours. Not weeks. Not the comfortable window your Change Advisory Board assumes when it schedules patches for next month’s maintenance window. 48 hours.

The gap between “published CVE” and “active exploitation in the wild” has collapsed so completely that the practical difference between a zero day and a known vulnerability is now almost nothing. By the time a CVE is public, scripted exploit tooling is already in development. By the time your team has triaged it, attackers have automated it. By the time your CAB has approved the patch, someone has already used it.

Every CVE disclosure is effectively your zero day now. The clock starts the moment it goes public.

AI Just Made This Worse on Both Ends

Here’s the part most threat reports gloss over, and it changes the calculus entirely.

The 48-hour exploitation window was already bad enough. Then AI got involved on the attacker side. Today, when a CVE drops, threat actors aren’t sitting down to manually write exploit code. They’re using LLMs to analyse the vulnerability, understand the affected code path, and generate working proof-of-concept exploits in minutes. The automation that once compressed exploitation from weeks to days is now compressing it from days to hours. The 48 hours Google documented isn’t a floor. It’s a ceiling that’s getting lower.

But that’s only half the story.

On the other side of the equation, AI coding assistants have fundamentally changed how fast software gets built. Teams are shipping code faster than ever before. Features that used to take weeks are landing in days. Entire services are being scaffolded by AI in hours. That’s genuinely useful progress. It’s also a security problem nobody is talking about honestly.

When developers move faster, dependencies get pulled in faster too. Libraries that a careful human reviewer might have scrutinised get added by an AI assistant without a second thought. New services get spun up with dependency trees nobody has fully mapped. Code gets pushed to production environments where it starts executing immediately, interacting with APIs, touching data, calling functions. And most security teams have no idea what’s actually running until something goes wrong.

So you’ve got AI on the attacker side compressing the exploitation window, and AI on the development side expanding the attack surface at machine speed. The 48-hour clock is ticking on a target that’s growing faster than any human team can manually track.

The maths here are not comfortable.

Rein’s documentation specifically addresses this new reality. As AI-generated code becomes standard, the behaviour of applications in production becomes harder to predict from static analysis alone. Code written or assisted by AI may introduce unexpected dependencies, call libraries in ways that weren’t anticipated, or drift from intended patterns in ways that only become visible at runtime. The only reliable way to understand what AI-coded applications are actually doing is to watch them do it.

The Third Multiplier: Your Enterprise AI Apps

There’s a third dimension to this that barely gets discussed, and it’s the one moving fastest right now.

Across every industry, organisations are deploying AI applications at a pace that would have been unimaginable two years ago. Not just AI coding assistants in developer workflows, but full enterprise AI products: autonomous agents that manage customer interactions, copilots that access internal knowledge bases, AI-powered workflows connected to CRMs, ERPs, billing systems, and HR platforms. Often deployed by business teams, often fast-tracked past the usual security review because the business case is compelling and urgency is high.

Each one of these is a new application. Each one has a dependency tree. Each one runs libraries. Each one makes API calls, invokes code, and touches data in production. And most organisations have almost zero visibility into what those applications are actually doing at runtime.

Here’s why that matters in the context of the Google report. An AI agent isn’t just vulnerable code sitting dormant in a repository. It’s autonomous. It acts. It calls APIs, processes data, and operates on behalf of users with whatever permissions it’s been granted. And because useful AI agents need broad access to be useful, they’re often granted a lot of it. When a CVE exists in a library that an AI agent actually invokes during normal operation, the blast radius isn’t limited to one application. It’s potentially everything that agent has been given access to.

The exploitation risk compounds with the access scope. A vulnerability in an AI agent connected to your document management system is a very different problem from the same vulnerability in an isolated microservice. Traditional scanners won’t tell you that the agent is actually calling the vulnerable library during real interactions. Only runtime observation can.

There’s another wrinkle specific to AI applications: their behaviour is genuinely harder to predict than conventional software. An AI agent responding to user prompts can call code paths that no static analysis anticipated. It can access resources in sequences that weren’t in the original design. It can drift from its intended behaviour in ways that only become visible in production. The attack surface of an agentic AI application isn’t fully defined until it’s running. Which means the only security model that actually works is one that observes it in real time.

What organizations actually need is dynamic runtime protection for agentic systems- something that can observe how agents behave in real time, understand when they drift from intended behavior, and enforce boundaries before that drift turns into risk. Static policies and pre-deployment checks aren’t enough when systems are autonomous and continuously evolving.

That’s the gap Rein was built to address. It brings AI discovery and runtime protection together as a core capability, not an add-on. When an agent or MCP-connected process starts to behave outside its expected path, Rein detects it and intervenes in real time- before it becomes an issue.

The teams getting this right aren’t holding back AI adoption- they’re creating the conditions to move faster, with confidence.

Why Patching Faster Isn’t the Real Answer

At this point the obvious response is: “fine, we’ll just patch faster.” If 48 hours is the window, build processes for 48 hours. Simple.

Except it isn’t.

Because the real reason teams can’t respond in 48 hours isn’t slow processes—it’s structural:

• Overwhelming noise – scanners surface thousands of vulnerabilities at once, most of which aren’t immediately relevant
• Sheer volume – a mid-sized organization can have tens of thousands of libraries across applications
• AI-driven sprawl – AI-assisted development accelerates dependency growth, often with little clarity on origin or behavior
• Lack of visibility – teams know what’s installed, but not what’s actually running or being executed

The result? A backlog no team can realistically triage in 48 hours.

So teams do what any rational person does when faced with an impossible workload: they prioritize by severity score, work the top of the list, and hope the rest don’t bite them. It’s not negligence-it’s math.

The problem is that severity scores are theoretical. A CVSS 9.8 vulnerability in a library your application never calls is less dangerous than a CVSS 6.5 in code that runs on every transaction. Scanners tell you what’s installed. They don’t tell you what’s running.

That gap is where attackers live.

The Question That Actually Matters: Is This CVE Reachable in Production?

The 48-hour clock is only scary if you’re trying to patch everything. If you can answer the question “does this CVE affect code that’s actually executing in my production environment right now?” the problem changes completely.

Most CVE alerts you receive are theoretical risk. The library is installed, the vulnerability exists, the CVSS score is alarming. But the vulnerable function was never called. It exists in a dormant dependency that nothing in your application actually touches. You didn’t need to panic. You needed to know.

Static reachability analysis-looking at code paths and dependency trees-tried to solve this problem, but it still falls short. It can’t see what the application is actually doing in production.

What’s needed instead is a dynamic runtime reachability approach-one that reflects real execution in real time, not just a more refined form of theoretical guessing.

Runtime observation gives you that answer. By watching what actually executes in production, which libraries are invoked, which functions are called, which APIs are active, you can separate the CVEs that are genuinely reachable in your environment from the ones that only exist on paper. That cuts the real-priority list from thousands to a handful. And a handful you can address in 48 hours.

This is the core idea behind what we build at Rein. Traditional security tools guess what your code might do. Rein knows what it’s doing right now, observing every library call, every API invocation, every dependency in real execution. When a CVE drops, Rein can tell you immediately whether the vulnerable component is actually running in production and whether the affected code path is reachable. Not a theoretical assessment. A live one. That’s just as important for human-written code as it is for the AI-generated code that’s increasingly shipping alongside it.

And What About the Time Before the Patch Lands?

Even with perfect prioritisation, patching takes time. Testing, staging, deployment pipelines, rollback plans: responsible remediation doesn’t happen instantly even when you know exactly what needs fixing.

That’s the window attackers are in. You know the CVE is real, you know you need to patch, and you’re in the process of doing it. But the clock is still running, and on the other side, AI-assisted exploit tooling is running faster than you are.

Runtime protection closes that gap. If Rein detects that a vulnerable code path is being exploited, it blocks the unsafe behaviour directly in runtime, without disrupting legitimate operations, without waiting for a patch to deploy. The application keeps running. The exploitation doesn’t.

It’s the difference between knowing your front door lock is broken and waiting for a locksmith to arrive versus having someone standing at the door in the meantime. The fix is still coming. You’re just not defenseless while you wait.

The Bigger Picture

Software vulnerabilities overtaking credentials as the primary attack vector isn’t a blip. It reflects a structural shift in how attackers operate: more automated, AI-assisted, and increasingly focused on the application layer that organisations manage themselves.

And the development side of that equation is shifting too. AI is writing code fast, deploying enterprise agents broadly, and connecting autonomous systems to the most sensitive corners of your infrastructure. The attack surface is growing at a pace that makes manual tracking genuinely impractical.

The response to that convergence isn’t to patch faster in a vacuum, slow down development, or halt AI adoption. It’s to know, at any given moment, which vulnerabilities in your environment are actually exploitable. Which libraries are running. Which code paths are reachable. What your applications and AI agents are genuinely doing right now, whether a human wrote them or an AI did.

Security from truth, not from theory. That’s what this moment requires, and what most current tooling still isn’t built to deliver.

The question isn’t whether your scanner is up to date. It’s whether it knows the difference between a vulnerability that’s installed and one that’s alive.