A high-severity flaw in ingress-nginx, the controller that routes traffic into a majority of the world’s Kubernetes clusters, is back in the spotlight five months after it was first patched. New research published by O3 Security on August 7, 2026 shows that CVE-2026-4342, a configuration-injection bug carrying a CVSS score of 8.8, still lurks in production clusters that never applied the March fix. It arrives alongside two lower-severity but actively tracked path-traversal bugs in Kubernetes’ SMB and NFS storage drivers, and a wave of container-security tooling updates from Microsoft, AWS, and Google meant to catch exactly this class of problem.

Taken together, the three CVEs (CVE-2026-4342, CVE-2026-3865, and CVE-2026-3864) illustrate a pattern that has become routine in cloud-native infrastructure: a component ships, gets adopted by nearly every managed Kubernetes offering, then becomes a durable attack surface long after its maintainers publish a fix. Ingress-nginx sits directly on the path between the internet and a cluster’s internal services, which is why security teams that ignored the March disclosure are scrambling now.

What CVE-2026-4342 actually does

CVE-2026-4342 is an improper input validation bug in k8s.io/ingress-nginx, the Kubernetes-maintained controller that translates Ingress resources into live NGINX configuration. According to O3 Security’s technical writeup, an attacker who can create or edit an Ingress object in a cluster (a permission granted to ordinary developers in most multi-tenant setups) can smuggle nginx configuration directives inside comment-style annotations. The controller parses those comments and folds them straight into the generated config file without sanitizing them first.

The practical result is arbitrary code execution inside the ingress-nginx controller’s pod, and from there, disclosure of any Kubernetes Secret the controller’s service account can read. The National Vulnerability Database lists the CVE record date as March 19, 2026, with corroborating advisories from GitLab on March 20 and SUSE on March 27. What changed in August is not the vulnerability itself but the scope of who is still exposed to it: five months on, O3 Security’s follow-up analysis flags it as one of the highest-impact unpatched Kubernetes bugs still circulating.

Fixed versions differ by release branch. Teams need 1.13.9 or later on the 1.13 line, 1.14.5 or later on 1.14, and 1.15.1 or later on 1.15, according to advisory data aggregated by GitLab’s security advisory database and Spain’s national CERT, INCIBE. Anyone pinning the Go module directly needs a version built after commit 5183b7d86137, dated March 19, 2026.

Two more CVEs hit Kubernetes storage drivers

Ingress-nginx isn’t the only component with an open wound. Kubernetes’ official CVE feed, last refreshed August 15, 2026, also lists two path-traversal bugs in the CSI (Container Storage Interface) drivers used to mount network file shares into pods.

CVE-2026-3865 affects the CSI Driver for SMB. Red Hat’s advisory and a technical breakdown from Kubernetes Recipes describe how the driver reads an attacker-controlled subDir value from a PersistentVolume’s handle and uses it, unvalidated, to build filesystem paths on the SMB share. A user with permission to create PersistentVolume objects can embed ../ sequences that cause the driver’s cleanup routine to delete or modify directories outside the volume it’s supposed to manage. It carries a CVSS of 6.5 and is fixed in driver version 1.20.1.

CVE-2026-3864 is the same bug pattern in the NFS CSI driver. OpenCVE’s record puts the disclosure at March 20, 2026, with a matching GitLab advisory dated March 21. It also scores 6.5 and is fixed in version 4.13.1. Both bugs require an authenticated user with PersistentVolume creation rights, so they’re most dangerous in clusters that hand out broad RBAC permissions to development teams, a common shortcut in fast-moving engineering orgs.

CVE severity and patch status at a glance

CVEComponentCVSSDisclosedVulnerable versionsFixed version
CVE-2026-4342ingress-nginx8.8 (High)March 19, 2026<1.13.9 / <1.14.5 / <1.15.11.13.9, 1.14.5, or 1.15.1
CVE-2026-3865CSI Driver for SMB6.5 (Medium)~April 11, 2026<1.20.11.20.1
CVE-2026-3864CSI Driver for NFS6.5 (Medium)March 20, 2026<4.13.14.13.1

Why this matters more in August than it did in March

Patches for all three bugs existed well before summer. What’s driving renewed attention now is a mix of timing and tooling. Kubernetes 1.37 is moving through its release cycle in August 2026, and managed-service providers are lining up support windows around it: Azure Kubernetes Service lists Kubernetes 1.37 with an upstream release in August 2026, AKS preview in September, and general availability targeted for October, according to Microsoft’s supported-versions documentation. Every version bump is a natural checkpoint for platform teams to also audit their ingress and storage add-ons, which is exactly when unpatched CVEs surface in change-review meetings.

Cloud vendors are responding with more scanning coverage, not fewer alerts. Microsoft’s Defender for Cloud release notes for July and August 2026 extend Kubernetes node vulnerability assessment beyond AKS to Amazon EKS and Google GKE, add scanning for Docker Hardened container images, and bring agentless threat protection to AWS and GCP workloads. Amazon’s own EKS platform-version notes show a steady drumbeat of patch releases, including a March 2026 update to Kubernetes 1.34 platform eks.18 explicitly labeled as carrying security fixes. None of this activity would be necessary if unpatched clusters weren’t still common enough to justify the engineering spend.

The blast radius: why ingress-nginx specifically is dangerous

Ingress-nginx isn’t a niche add-on. It is one of the two or three most commonly deployed ingress controllers in the Kubernetes ecosystem, sitting directly in front of internet-facing services on countless production clusters. That position is what makes CVE-2026-4342 worse than a typical medium-severity RBAC-gated bug: because Ingress resources are routinely delegated to application teams in multi-tenant clusters, the “attacker” doesn’t need cluster-admin rights or a network foothold. They need only the same Ingress-editing permission that most CI/CD pipelines already grant to automated deploy tooling.

O3 Security’s advisory specifically calls out shared, multi-tenant clusters as the highest-risk environment, since a single malicious or compromised tenant can pivot into secrets belonging to every other workload the controller can see. That is a materially different threat model than a single-tenant cluster where every Ingress author is already trusted.

What no advisory will tell you: exposure counts are missing

One notable gap in the public record: none of the advisories from Red Hat, SUSE, GitLab, NVD, INCIBE, or O3 Security publish a hard number for how many live clusters remain vulnerable. Each describes the bug class as affecting “any deployment using ingress-nginx” or “any cluster running the vulnerable CSI driver,” language that is accurate but not quantified. That’s a contrast with incidents like FortiBleed, where Shodan-style internet scans produced a concrete count of exposed devices. Kubernetes ingress controllers generally sit behind cloud load balancers rather than directly on the public internet, which makes them harder to enumerate from the outside and is likely why no researcher has published a scan-based estimate.

The absence of a number doesn’t mean the risk is small. It means defenders have to rely on internal asset inventory rather than an external tracker to know if they’re affected, which is a harder, slower process and one reason these bugs still make news five months after disclosure.

Kubernetes 1.37 and the managed-service adoption timeline

Context matters here: Kubernetes itself ships a new minor version roughly every four months, and each managed provider runs its own support lag behind the upstream release. Azure’s own version table shows the previous release, Kubernetes 1.36, had an upstream release in April 2026, AKS preview in May, and AKS general availability in June, a roughly two-month lag from upstream to GA. Applying that same cadence to 1.37 puts AKS general availability around October 2026, with end-of-life not until October 2027 and long-term support extending to October 2028.

Google’s multi-cloud GKE product, which lets teams run GKE-managed control planes against clusters hosted on AWS, currently lists support for a spread of versions including 1.35.3-gke.300, 1.34.6-gke.200, and 1.33.10-gke.200, according to Kubernetes’ own release documentation cross-referenced with GKE’s release notes. That spread is normal: enterprise clusters rarely run bleeding-edge Kubernetes, which is precisely why CVEs disclosed against ingress-nginx or CSI drivers months ago can still be live in clusters running perfectly supported, just outdated, add-on versions.

Competitive comparison: how AWS, Microsoft, and Google are responding

The three big managed Kubernetes providers are converging on the same defensive playbook (broader vulnerability scanning, agentless coverage, and cross-cloud parity) but they’re not moving at the same pace.

ProviderManaged K8s serviceContainer/node vuln scanningCross-cloud coverageKubernetes 1.37 timeline
Microsoft AzureAKSDefender for Cloud, node + image scanningExtended to EKS and GKE (Jul-Aug 2026 update)Preview Sep 2026, GA ~Oct 2026
Amazon Web ServicesEKSPlatform-version patch notes, security-fix releasesNative only; covered by Defender when customer opts inTracks upstream via platform versions
Google CloudGKE / GKE on AWSGKE Security Posture dashboardGKE on AWS supports multi-cloud clusters nativelyRolling version support (1.33-1.35 tracked mid-2026)

Microsoft’s move to extend Defender scanning to EKS and GKE node vulnerabilities is the most direct acknowledgment that customers run mixed-cloud Kubernetes fleets and want one pane of glass regardless of who manages the control plane. AWS and Google haven’t announced equivalent cross-cloud vulnerability scanning of their own; instead, both rely on frequent platform-version patch trains and their native security posture tooling.

Historical context: ingress controllers keep becoming the entry point

Ingress-nginx has a track record here. Configuration-injection and admission-controller bugs in the project have surfaced periodically since Kubernetes ingress became the default way to expose services, largely because the controller’s job (translating user-supplied YAML into live proxy configuration) inherently means untrusted input reaches a privileged process. The pattern echoes other infrastructure-adjacent CVEs this site has tracked this year, including the Palo Alto GlobalProtect authentication bypass and the cPanel/WHM auth bypass that hit 1.5 million servers: widely deployed edge or control-plane software, a patch that ships quietly, and a long tail of unpatched instances that resurface in security research months later.

What’s different about the Kubernetes storage-driver bugs is the trust boundary. CVE-2026-3865 and CVE-2026-3864 don’t require a network attacker at all, just an already-authenticated cluster user with fairly ordinary permissions. That’s a reminder that Kubernetes RBAC misconfiguration, not just external exposure, remains one of the more common root causes behind cloud-native incidents.

Market impact: container security spending keeps climbing

Vendors aren’t shipping these detection features for free, and the timing lines up with continued enterprise investment in container and Kubernetes security tooling. Microsoft’s July-August 2026 Defender for Cloud update didn’t just add EKS and GKE node scanning, it also brought generally-available discovery and posture management for serverless container workloads like Azure Container Apps, Azure Container Instances, and AWS Fargate-backed ECS. That’s a direct product response to customers running mixed workloads across Kubernetes, serverless containers, and traditional VMs, and wanting a single vulnerability feed across all three rather than stitching together per-cloud tools themselves.

For platform teams, the practical takeaway is that vulnerability management for Kubernetes add-ons (ingress controllers, CSI drivers, admission webhooks) needs the same patch cadence discipline as the control plane itself. Add-ons are frequently treated as “set and forget” once installed via Helm, which is exactly the gap CVE-2026-4342 has been quietly exploiting the visibility around.

How to check if your cluster is exposed

Security teams can check ingress-nginx exposure with a straightforward version query against the running controller image:

kubectl get deployment -n ingress-nginx ingress-nginx-controller \
  -o jsonpath='{.spec.template.spec.containers[0].image}'

# Compare the tag against the fixed releases:
# 1.13.9, 1.14.5, or 1.15.1 (or later)

For the CSI driver bugs, teams should inventory installed driver versions the same way:

kubectl get pods -n kube-system -l app=csi-smb-controller \
  -o jsonpath='{.items[0].spec.containers[*].image}'

kubectl get pods -n kube-system -l app=csi-nfs-controller \
  -o jsonpath='{.items[0].spec.containers[*].image}'

Beyond version checks, security teams should also review who can create or edit Ingress and PersistentVolume objects. Tightening that RBAC surface closes the practical attack path even before a patch rolls out, and it’s a control that pays off against future CVEs in the same components, not just these three.

Predictions: where this heads next

  • More cross-cloud scanning parity. Expect AWS and Google to respond to Microsoft’s EKS/GKE Defender coverage with their own expanded posture-management features by early 2027, since ceding that ground to a competitor’s control plane isn’t sustainable.
  • Ingress-nginx scrutiny won’t end with this CVE. Given the project’s history of periodic configuration-injection bugs, expect at least one more moderate-to-high severity ingress-nginx CVE disclosed before the end of 2026.
  • Kubernetes 1.37 adoption will be gradual. Based on the 1.36 rollout pace, AKS GA for 1.37 likely lands around October 2026, with EKS and GKE following on their own independent timelines rather than a synchronized release.
  • RBAC auditing tools gain traction. As both CSI driver bugs hinge on over-permissioned PersistentVolume creation rights, expect more platform teams to adopt automated RBAC-drift detection as a standard part of cluster hardening.
  • Slow patch cycles keep old CVEs newsworthy. Because no vendor publishes internet-scan-based exposure counts for internal Kubernetes components, expect security researchers to keep re-surfacing “old” CVEs like this one every few months as a reminder, rather than exposure numbers driving one-time news cycles the way internet-facing CVEs do.

Frequently asked questions

Is CVE-2026-4342 being actively exploited?

None of the advisories reviewed, including O3 Security, NVD, SUSE, and GitLab, report confirmed in-the-wild exploitation. The risk is treated as high because of the low bar for exploitation (standard Ingress-editing permissions) rather than any observed attack campaign.

Which ingress-nginx versions are safe?

Version 1.13.9 or later on the 1.13 branch, 1.14.5 or later on 1.14, and 1.15.1 or later on 1.15 are patched, per GitLab’s and INCIBE’s advisory data.

Does this affect EKS, AKS, and GKE customers directly?

No vendor-branded advisory names EKS, AKS, or GKE specifically. Because ingress-nginx and the affected CSI drivers are commonly self-installed add-ons rather than baked into the managed control plane, exposure depends on what each customer deployed, not the underlying cloud provider.

What permissions does an attacker need for the CSI driver bugs?

An authenticated cluster user needs the ability to create PersistentVolume objects referencing the vulnerable SMB or NFS CSI driver. This is typically a namespace-admin or storage-admin level permission, not cluster-admin.

How is this different from a typical internet-facing CVE?

All three CVEs require some form of existing cluster access, either the ability to edit Ingress resources or create PersistentVolumes, rather than being reachable by an anonymous internet attacker. That lowers the blast radius compared to something like an unauthenticated remote code execution bug, but raises the stakes in shared, multi-tenant clusters where many teams already hold that access.

When does Kubernetes 1.37 become generally available on major clouds?

Azure’s own documentation lists an upstream release in August 2026, AKS preview in September 2026, and AKS general availability targeted for October 2026. AWS and Google have not published matching public timelines as of this writing.

Should I upgrade ingress-nginx immediately or wait for a maintenance window?

Given the CVSS 8.8 rating and the low permission bar for exploitation, security researchers who reviewed the bug recommend treating it as an out-of-cycle patch rather than waiting for a routine maintenance window, particularly in multi-tenant clusters.

Are there mitigations if I can’t patch right away?

Restricting who can create or modify Ingress and PersistentVolume objects through tighter RBAC policies reduces exploitability even before the underlying component is upgraded, since all three CVEs require that level of cluster access to trigger.