CLOUD SECURITY • Updated September 16, 2026

GKE Fragnesia Vulnerability CVE-2026-46300: Affected Nodes, Fixed Versions & Mitigations

Fragnesia (CVE-2026-46300) is a Linux-kernel container breakout vulnerability documented by Google Cloud. In GKE, it affects Standard clusters using Ubuntu node images and can let an unprivileged local attacker escalate to root on the host. Google says Standard clusters using Container-Optimized OS, Autopilot clusters and workloads protected by GKE Sandbox are not impacted by this GKE exposure.

Fragnesia in 60 Seconds

CVE	CVE-2026-46300
Google bulletin	GCP-2026-033
GKE severity	Medium
Attack result	Local privilege escalation from an unprivileged context to root on the host
Affected GKE configuration	GKE Standard clusters with Ubuntu nodes
Not impacted in Google’s bulletin	Standard with Container-Optimized OS, GKE Autopilot, GKE Sandbox
Primary action	Upgrade Ubuntu node pools to Google’s fixed GKE versions or later

Source: Google Cloud GKE security bulletin, updated July 16, 2026.

What Is the Fragnesia Container Breakout?

Containers isolate workloads by sharing the host Linux kernel while using namespaces, cgroups and other controls to separate processes. A container breakout is dangerous because a flaw can let code escape that isolation and gain privileges on the underlying node.

Google’s bulletin says Fragnesia allows an unprivileged local attacker to escalate to root on the host. In practical terms, an attacker would first need a foothold that lets them execute code in a relevant local/container context; this is not described by Google as a one-click unauthenticated internet exploit.

The impact matters because root access on a Kubernetes worker node can expose other workloads, node credentials, mounted secrets, local data and control paths that were never meant to be reachable from the original container.

Are Your GKE Clusters Affected?

Affected: Google lists GKE Standard clusters using Ubuntu node images as impacted.

Not impacted in the GKE bulletin:

GKE Standard clusters with Container-Optimized OS nodes
GKE Autopilot
Clusters or workloads using GKE Sandbox

If a fleet mixes Ubuntu and Container-Optimized OS node pools, assess each pool separately rather than treating the entire cluster as one security state. Also remember that application risk still depends on who can run code in containers, workload privileges, network exposure, service-account permissions and secrets mounted into affected workloads.

Do Not Treat a Container as a Strong Security Boundary

Google explicitly warns that containers do not provide a robust security boundary against container-breakout flaws. For workloads that need stronger isolation, Google recommends GKE Sandbox. That advice is bigger than this one CVE: patching reduces known risk, while isolation architecture limits the blast radius when the next kernel or runtime flaw appears.

Fixed GKE Versions for Ubuntu Node Pools

Google’s July 16 update lists the following GKE versions as containing the fix for Ubuntu node pools. Upgrade to the listed version or later within the same supported minor line:

GKE minor line	Fixed version or later
1.30	1.30.14-gke.2710000
1.31	1.31.14-gke.2116000
1.32	1.32.13-gke.1829000
1.33	1.33.13-gke.1011000
1.34	1.34.9-gke.1131000
1.35	1.35.6-gke.1127000
1.36	1.36.2-gke.1346000

Do not downgrade a newer secure patch just to match this table. If your node pool is already on a later supported patch release, the relevant fix should be included. Availability can vary by release channel and region, so use the versions offered for your cluster and confirm them against the current Google Cloud bulletin.

5 Actions GKE Administrators Should Take Now

1. Inventory node images and versions

Identify every Standard node pool using Ubuntu and record its current GKE version. Mixed-image clusters need pool-by-pool review.

2. Upgrade affected Ubuntu node pools

Move each affected pool to Google’s fixed version for its minor line or a later supported patch. Use a staged rollout for production fleets and validate scheduling, disruption budgets, ingress, storage and critical daemonsets after the upgrade.

3. Move workloads away from root where possible

Google recommends running workloads as non-root when feasible. This does not replace patching, but it reduces exposure to classes of privilege-escalation attacks.

4. Apply seccomp and block privilege escalation

For workloads that need stronger defaults, Google recommends seccompProfile.type: RuntimeDefault and setting allowPrivilegeEscalation: false where application requirements permit it.

5. Use GKE Sandbox for untrusted workloads

For multi-tenant, user-submitted, plugin, build or otherwise untrusted code, consider GKE Sandbox so the workload does not rely only on the ordinary container boundary.

How to Verify Your GKE Security Posture After Patching

After upgrading, verify the result instead of assuming the maintenance event completed exactly as planned:

Confirm every Ubuntu node pool is on the intended fixed or later GKE patch.
Confirm old vulnerable nodes have actually drained and disappeared rather than remaining in a partially upgraded pool.
Check application health, pod restarts, daemonsets, persistent volumes and load-balancer backends.
Review Kubernetes and Cloud Audit Logs for unexpected privileged pod creation, exec activity or unusual node-level behavior.
Confirm high-risk namespaces enforce the security controls your platform team expects.
Enable GKE security bulletin notifications so future advisories are tied to affected cluster configurations.

Google also recommends release channels, automatic node upgrades and regular patching. For clusters that do not use automatic upgrades, the company recommends upgrading node pools at least monthly.

Frequently Asked Questions

Is CVE-2026-46300 remotely exploitable?

Google describes it as a vulnerability that lets an unprivileged local attacker escalate to root on the host. That is different from an unauthenticated remote internet exploit.

Does Fragnesia affect every GKE cluster?

No. Google’s GKE bulletin specifically identifies Standard clusters with Ubuntu nodes as impacted and says Container-Optimized OS nodes, Autopilot and GKE Sandbox are not impacted by this GKE exposure.

Does patching the control plane alone fix the issue?

This vulnerability is tied to the Linux kernel on affected Ubuntu nodes, so administrators should ensure the affected node pools reach a fixed GKE version. Do not assume a control-plane-only update means worker nodes are protected.

Should we switch every workload to GKE Sandbox?

Not necessarily. Sandbox adds stronger isolation and is especially valuable for untrusted or higher-risk workloads. Architecture, compatibility, performance and cost requirements still matter.

Can non-root containers still be useful after patching?

Yes. Least privilege is defense in depth: it reduces opportunities for many exploitation paths even when a specific known CVE has already been patched.

Sources & Related Digital Pulse Brief Coverage

Primary sources:

Related coverage:

Editorial note: This guide explains vendor-published security information for defensive administration. Always confirm the current bulletin and release availability for your own GKE region, release channel and support status before changing production clusters.