The Patch Gap Is the Attack Window: Google's Cloud Threat Horizons Report H1 2026

Commissioned, Curated and Published by Russ. Researched and written with AI.

What’s New

12 March 2026: The most consequential number in the Google Cloud Threat Horizons H1 2026 report isn’t the 48-hour exploitation window for React2Shell. It’s 83%. Identity compromise – stolen credentials, misconfigured service accounts, abused IAM roles – underpinned 83% of all cloud intrusions observed in H2 2025. Attackers aren’t breaking in. They’re logging in. That’s a different threat model, and perimeter security is the wrong answer to it. The secondary implication is where this is heading: AI agents authenticate to cloud resources using service accounts and long-lived API keys, most of them over-permissioned with no just-in-time scoping. As agent deployments scale, the non-human identity layer is becoming the largest unaudited attack surface in the enterprise.

Changelog

A vulnerability in XWiki was patched in June 2024. In November 2025 – 17 months later – crypto miners found it. Google’s security team documented the attack chain in detail. That gap, between patch availability and widespread deployment, is your risk window. Attackers are now scanning for it systematically, at scale, with AI assistance.

This is the core finding of Google’s Cloud Threat Horizons Report H1 2026, published this week and based on Google Cloud Security’s observations across the second half of 2025. The report is worth reading in full. What follows is the engineering read – the parts that should change how you think about patching, dependencies, and your Kubernetes configuration.

The Exploitation Window Has Collapsed

Google’s report states it plainly: “The window between vulnerability disclosure and mass exploitation collapsed by an order of magnitude, from weeks to days.”

The clearest example is CVE-2025-55182, known as React2Shell. This is a remote code execution vulnerability in React Server Components – a widely used JavaScript framework for building server-rendered UIs. The vulnerability was publicly disclosed, and within 48 hours Google Threat Intelligence Group was observing active exploitation in the wild.

Forty-eight hours. Not weeks. Not days after some attacker noticed it. Two days after public disclosure, while engineering teams were still triaging their backlog and deciding whether it applied to their stack.

This is what AI-assisted attack tooling does to the timeline. Automated scanning identifies affected systems at internet scale. Exploit generation turns a CVE description into working code faster than a human red team can. The attacker doesn’t need to be clever. They need to be fast, and the tooling makes them fast.

For engineering teams operating on weekly patch cycles or monthly vulnerability reviews, this is a structural problem, not a process one. The window closes before the process completes.

Third-Party Code Is the New Perimeter

The report is unambiguous about where attacks are landing: not on the core infrastructure of AWS, Azure, or GCP, but on the third-party software running on top of it.

“Google Cloud’s underlying infrastructure remains secure,” the report notes. “Threat actors are successfully targeting unpatched applications and permissive user-defined firewall rules.”

This is the predictable consequence of where security investment has gone over the past decade. The hyperscalers have hardened their control planes, their IAM systems, their network primitives. They’re well-defended. The dependencies – the npm packages, the Java libraries, the React frameworks, the XWiki instances, every open source component in the build – are the soft underbelly. You didn’t write them, you may not track them closely, and you patch them slowly.

CVE-2025-24893 (XWiki) is the canonical example. XWiki Platform allows arbitrary remote code execution by sending a crafted search string. The patch was available in June 2024. It required no complex migration, no architectural change – just deploying the patched version. Seventeen months later, it was being actively exploited for crypto mining.

The XWiki case is worth sitting with. This isn’t a zero-day. This isn’t sophisticated tradecraft. It’s a known vulnerability with a published CVE, a published patch, and a searchable list of internet-facing instances. The attacker’s only requirement was that you hadn’t patched it yet. Across the internet, enough organisations hadn’t.

This is the same root problem as supply chain attacks via third-party tooling – the code you didn’t write is attacking you through the trust relationship you gave it. The difference here is the mechanism: not malicious insertion, but delayed patching of known vulnerabilities.

AI on Offence: What It Actually Looks Like

The report documents AI-assisted attacks across multiple phases of the kill chain, not just exploit generation.

Recon is faster. AI-assisted scanning can identify vulnerable instances at internet scale by correlating banner responses, service fingerprints, and disclosed CVEs. What used to require a dedicated human operator doing OSINT can now run continuously and automatically.

Target selection is more precise. The UNC4899 North Korea case (detailed below) involved luring a specific developer with a convincing open source collaboration pretext. The social engineering was targeted, not spray-and-pray.

Lateral movement is more automated. The report describes a supply chain incident where threat actors used large language models to automate credential harvesting and pivot from a developer’s local environment to full cloud administration access – within 72 hours, via an OpenID Connect trust relationship between a CI/CD provider and the cloud platform.

The report’s recommendation is direct: “Organizations should be turning to more automatic defenses.” Manual review cycles and human-in-the-loop security processes are structurally mismatched against automated attack tooling. The response needs to operate at the same speed as the threat.

This connects to a broader pattern described elsewhere: autonomous agents operating in attack chains that can adapt and pivot without human intervention. The Google report is the enterprise cloud side of the same empirical trend.

The Kubernetes Angle

The UNC4899 incident deserves its own section. It’s the most detailed attack chain in the report and it targets something most cloud engineering teams run.

UNC4899 is assessed to be a North Korean state-sponsored threat actor. Their attack chain started with social engineering: a developer was lured into downloading an archive file under the pretext of an open source project collaboration. The developer transferred the file from their personal device to their corporate workstation via AirDrop – bridging the personal-to-corporate air gap through a mechanism most security policies don’t address.

Using an AI-assisted IDE, the developer interacted with the archive’s contents and executed embedded malicious Python code. The code spawned a binary masquerading as kubectl – the Kubernetes command-line tool. The binary beaconed to UNC4899-controlled infrastructure, establishing a backdoor. From there, the threat actors pivoted through the corporate network to the Kubernetes workloads, ultimately stealing millions in cryptocurrency.

A few things to note about this chain:

The entry point was a personal device and AirDrop. Not a phishing email. Not a compromised credential. A personal device used for what looked like routine file transfer.

The disguise was kubectl. This is a tool developers run constantly, in terminals, against production clusters. A process masquerading as kubectl is not going to trigger immediate suspicion.

The target was Kubernetes workloads with access to cryptocurrency assets. The actor knew what they were after and navigated to it.

If your Kubernetes RBAC is permissive, your workload identity configs are default-or-worse, or your developers’ personal devices can bridge to corporate workloads via AirDrop or similar, the UNC4899 chain is a realistic threat model for you.

Identity Is the Actual Perimeter

The patch gap story is real and the exploitation timeline data is damning. But the deeper finding in the report is this: 83% of cloud intrusions observed in H2 2025 started with an identity failure.

Stolen credentials. Misconfigured service accounts. Abused IAM roles. Attackers aren’t exploiting novel vulnerabilities in Google’s infrastructure – they’re authenticating with legitimate-looking identities that have been harvested, misconfigured into exposure, or inherited through a compromised CI/CD pipeline. Both React2Shell and the XWiki exploitation chain are consistent with this pattern: the vulnerability creates access, but it’s the identity that gets pivoted. In the UNC4899 Kubernetes case, the kill chain ran from developer endpoint to cloud administration via CI/CD service account tokens that nobody had constrained.

The security industry has known for years that identity is the dominant attack surface in cloud environments. The Verizon DBIR has said it every year. The 83% figure in this report says it again, with documented incident data from H2 2025. The response from most enterprises has been to add MFA to human accounts and call it done. That addresses maybe a fraction of the problem.

The harder half is non-human identity: the service accounts, the API keys, the OIDC trust relationships, the CI/CD pipeline credentials. These are issued for operational convenience, scoped broadly because scoping them narrowly takes time nobody has, and left indefinitely because rotating them breaks things and rotation is manual. An attacker who reaches one of these identities – through a supply chain compromise, a developer credential harvest, or a misconfigured public endpoint – doesn’t need to escalate privilege. They already have it.

Traditional perimeter security is the wrong mental model for this threat. The perimeter is the identity. If an attacker holds a valid credential with sufficient scope, they are, from the cloud control plane’s perspective, an authorised user.

AI Agents Are the Next Identity Problem

The non-human identity problem is about to get significantly larger.

AI agents – the kind being deployed across enterprise environments right now, calling APIs, reading data stores, triggering workflows, writing to databases – authenticate using service accounts and API keys. They require broad access to do their jobs. They run continuously. Their credentials are typically persistent, not just-in-time. Most organisations don’t have a governance framework for them, because the governance frameworks were designed for human users.

The Google report specifically flags “weaponized local AI tooling” as an emerging attack vector. The QUIETVAULT incident is the clearest example in the data: a malicious NPM package embedded a credential stealer that used the LLM already resident on the developer’s endpoint to enumerate and extract sensitive configuration files. The attacker didn’t install AI. The developer’s own AI development environment provided it, trusted by the OS, invisible to endpoint detection tooling tuned for malicious binaries.

That’s the current threat. The near-term threat is the agents themselves.

An enterprise AI agent provisioned with standing access to cloud storage, databases, and internal APIs represents a high-value identity target. When that agent is compromised – via prompt injection, supply chain attack on its tooling, or direct credential theft – the attacker inherits the agent’s permissions. Not a developer’s permissions. Not a service account with access to one bucket. An autonomous actor that can traverse the environment at machine speed with whatever scope the agent was given.

Most enterprise AI agents are over-permissioned. The pressure to ship working agents fast produces the same dynamic as the human identity problem: provision more than necessary, review it later, never review it. The difference is scale and speed. A compromised human account moves at human speed. A compromised agent does not.

The practical implication is straightforward, even if the operational reality is harder: AI agent service accounts should be treated like privileged human accounts. That means least-privilege scoping from the start, just-in-time access rather than standing permissions, regular rotation of credentials, and audit logging that actually gets reviewed. Privileged Identity Management frameworks exist for human admin accounts. The same discipline applies here, and most teams haven’t started applying it.

What Engineering Teams Should Actually Do

Six changes, roughly ordered by impact-to-effort ratio:

1. Measure time-to-patch for critical CVEs in hours, not weeks. If React2Shell is patched within 48 hours of exploitation starting, a weekly patch cycle doesn’t protect you. Set an SLO. Critical CVEs (CVSS 9+, active exploitation) need a response window measured in hours. This requires automation – you cannot manually triage at this speed across a non-trivial dependency tree.

2. Make dependency scanning continuous, not periodic. Point-in-time vulnerability scans miss the gap between scans. Runtime scanning that flags newly disclosed CVEs against your deployed dependency inventory, and alerts automatically, is the baseline. Tools like Dependabot, Renovate, or commercial equivalents can automate the pull request; your job is to set the SLO and close it.

3. Maintain an SBOM and actually use it. You cannot patch what you don’t know you’re running. Software bills of materials are not a compliance checkbox – they’re the prerequisite for any meaningful vulnerability response. If a CVE drops for a Java library and you don’t know which services use it, your response time starts from zero. The SBOM is the inventory that makes fast response possible.

4. Audit your Kubernetes RBAC and workload identity configuration. The UNC4899 case involved pivoting through Kubernetes to cryptocurrency assets. Default RBAC configurations are frequently overly permissive. Workload identity bindings that grant broader cloud permissions than the workload needs are a lateral movement enabler. This isn’t a zero-day fix – it’s a configuration review that most teams haven’t done recently.

5. Treat cryptominer infections as indicators of broader exposure. The XWiki exploitation involved crypto miners as the payload – but crypto mining is often the first, observable symptom of a compromised system, not the worst thing the attacker could have done. If you find a miner, assume the vulnerability it exploited is also being used for persistence, data exfiltration, or lateral movement. Investigate the entry point, not just the payload.

6. Apply PIM discipline to AI agent service accounts. Every AI agent in your environment has an identity. Audit what each one can access. Scope permissions to the minimum required for the specific workflow, not the maximum convenient for the team that built it. Use short-lived credentials where the platform supports it. Log agent API calls with the same rigour as privileged human access. If you wouldn’t give a human contractor standing admin access to your cloud environment, don’t give it to an agent.

There’s a related prompt injection and supply chain surface worth reviewing if your stack includes AI tooling with third-party integrations – the attack surface there extends the same dependency problem into a new domain.

The Patch Backlog Is an Active Risk Window

The standard framing for patch debt is technical debt: something to address eventually, scheduled for a future sprint, tracked on a board somewhere, de-prioritised when delivery pressure builds.

The Google report, backed by documented incidents from the second half of 2025, makes a different case. The patch backlog is not deferred maintenance. It’s a list of open attack windows, each with a disclosure date stamped on it, discoverable by anyone running automated scanning against your IP ranges.

XWiki CVE-2025-24893 was in patch backlog for 17 months before exploitation became widespread. React2Shell was exploited while it was still in triage for most teams. The XWiki case is instructive precisely because it isn’t a zero-day story – it’s a known-vulnerability-nobody-deployed-the-patch story. That’s a more common failure mode, and it’s more preventable.

The identity finding adds a second axis to this. 83% of intrusions didn’t require a vulnerability at all – they required an identity that was accessible and over-scoped. Patch debt and identity debt are different problems with the same root cause: the operational cost of doing the right thing gets deferred until the cost of not doing it lands as an incident.

AI agents are expanding the identity debt surface faster than most organisations are tracking it. The question isn’t whether an AI agent will be the entry point for a significant cloud compromise. The question is when, and whether your IAM posture will limit the blast radius when it happens.

Sources: Google Cloud Threat Horizons Report H1 2026 | Security Boulevard: 83% of Cloud Breaches Start with Identity | ZDNet coverage | CVE-2025-55182 | CVE-2025-24893