Kubernetes security relies on a single, massive assumption: that the container runtime and the Linux kernel will successfully isolate workloads from the host. Because teams trust this boundary, they often treat front-end pods as disposable, low-privilege environments protected by network policies, service-account scoping, and container walls to keep them safe. However, that safety net vanishes the moment an attacker targets the underlying host kernel directly.

Recent Linux kernel vulnerabilities—Copy Fail, Dirty Frag, and Fragnesia—provide a local privilege escalation path within the shared Linux kernel, affecting the entire node. While these flaws do not grant unauthenticated remote access on their own, threat actors can chain them with application-layer exploits. An attacker first gains execution inside a workload (often through a weakness at the ingress layer) and then deploys kernel-level primitives to bypass the pod/host isolation boundary. Success allows a local privilege escalation on the underlying host, granting full control over the Kubernetes cluster unless platforms like ExtraHop Reveal(x) intercept the initial ingress manipulation or subsequent cluster pivots.

Analyzing these Linux vulnerabilities alongside recent kernel escalations maps the exact steps required to establish pod access, break container boundaries, and enumerate infrastructure post-compromise. This technical analysis demonstrates why out-of-band monitoring with ExtraHop Reveal(x) provides the essential visibility needed to uncover the API anomalies and east-west traffic patterns that accompany such exploit chains.

Initial Access Vectors: Breaking Through the Ingress and App Layers

Attackers must establish an initial foothold inside the Kubernetes (K8s) environment before they can exploit host-kernel flaws. In production clusters, attackers typically target one of two exposed components: the ingress path routing external traffic into the cluster or the application code processing that traffic.

Ingress Vulnerabilities: NGINX Rift & Pool Slip

Deploying nginx at the edge as an ingress controller, API gateway, or reverse proxy makes edge-layer memory safety a core threat model requirement. A single flaw in this routing path can elevate a standard external HTTP request into direct remote code execution (RCE). Two recent vulnerabilities highlight this risk:

• NGINX Rift (CVE-2026-42945): A heap-based buffer overflow vulnerability in the ngx_http_rewrite_module. A specific rewrite configuration that combines unnamed PCRE captures with a replacement string containing a question mark (?) triggers the vulnerability.
• nginx-poolslip (CVE-2026-9256): A memory allocation boundary vulnerability occurring during connection multiplexing. An attacker manipulates recycled headers to crash the worker processes to cause a DoS or achieve RCE.

App-Level Vulnerabilities: React2Shell (CVE-2025-55182)

Attackers often bypass the ingress layer entirely, prioritizing application-level targets instead. Exploits like React2Shell grant unauthenticated, direct access to Kubernetes pods.

Breaking the Boundary: Page Cache Manipulation via Local Privilege Escalation

React2Shell was successfully exploited to establish a foothold, but now the attacker is trapped inside the container environment. Standard hardening configurations attempt to contain adversarial movement by implementing non-root users, read-only root filesystems, and dropped Linux capabilities.

But what happens when the attacker decides to target the host kernel itself?

A specific class of Linux local privilege escalation (LPE) vulnerabilities leverages zero-copy memory architecture to bypass container boundaries. Because containers share the host's Linux kernel, they also share the underlying memory page cache. An unprivileged user inside a pod can abuse system calls like splice() to pass a reference to a read-only host binary, such as /usr/bin/su, into a vulnerable kernel subsystem. This forces the kernel to execute an in-place write directly to RAM, altering the cached file for all running processes on the host without ever modifying the file on disk.

Three LPE vulnerabilities in Linux abuse this exact mechanism:

Breaking the Boundary Walkthrough

A practical walkthrough demonstrates the tactical execution of chaining the React2Shell (CVE-2025-55182) and Copy Fail (CVE-2026-31431) vulnerabilities to achieve a container breakout.

Initial access occurs when the attacker targets a vulnerable application layer and a basic route.ts[1] file using React2Shell.

The successful React2Shell exploitation lands the attacker on the compromised pod. From this position, the attack path pivots to the node using Copy Fail.

The pods running on the node present the following configuration from the jumpbox terminal:

Starting with a known Copy Fail PoC, the attacker must verify a configuration match with the kube-control running in the K8s cluster.

Executing the kubectl describe pod command exposes the configuration details of the running EKS[2] instance. In this scenario, the pod uses an eks-minimal container base image.

Because these escalations rely on exploiting the shared backing page, an attacker must port the exploit to the active instance and verify that the target image hashes match.

Through an SSH connection the attackers see that both the kube-proxy and copy-fail containers are present. Inspecting the respective image file hashes reveals that the lower storage layers are completely identical, ensuring the environment is primed to exploit.

The original PoC uses `ipset`, but because the target environment lacks that utility, modifying the script to target `iptables` ensures execution compatibility. K8s executes `iptables` periodically during pod and route creation. With the matching-layer PoC successfully deployed, forcing an `iptables` command event will trigger the exploit.

The execution payload relies on the following logic:

Opening a file descriptor for `dmesg` captures the underlying kernel messages, confirming a successful node escape with kernel administrative privileges. The payload then writes a string to /var/log/secrets to demonstrate persistent arbitrary file write capabilities on the host.

With the trigger installed via our deployed YAML file, executing the `sudo dmesg` command verifies the current state of the kernel log buffer. A clear `dmesg` output indicates that while the page cache manipulation has successfully occurred, the exploit has not yet executed the final payload stage.

Removing the copy-fail pod and clearing the modified `iptables` rules cleans up the footprint once they are no longer necessary. To ensure the attack functions correctly, an attacker must either clone a version of the kube-system configuration or modify the deployment YAML to incorporate a custom ConfigMap. The most efficient method to force this recreation involves deleting the running kube-proxy pod, which prompts the Kubernetes control plane to automatically restart a fresh instance.

Outside of a fat fingered pod name, everything worked as expected! Check the node’s dmesg again to observe what happened.

The `dmesg` log buffer confirms the execution of the copy-fail exploit and the creation of the secret, demonstrating the ability to write to the node’s kernel message space directly from a pod container.

Verifying the presence of the exfiltrated data requires reading the target file on the host with `cat /var/log/secrets`.

The output confirms that the copy-fail vulnerability successfully breaks the pod-to-node isolation boundary, enabling arbitrary file write and execution directly against the underlying host node.

Tying It All Together

The typical adversarial lifecycle chains these execution vectors into a multi-stage attack progression:

1. External Ingress: The attacker exploits an unauthenticated RCE vulnerability, targeting edge deployment layers like the nginx configurations or react server components.
2. Compromised Pod: The attacker establishes an initial foothold inside the containerized application environment.
3. Cross-Boundary Escape: The attacker exploits a shared host-kernel vulnerability—such as Copy Fail, Dirty Frag, or Fragnesia—to bypass container isolation.
4. Host Node (Root): The attacker gains full administrative control over the underlying host node. From this root position, lateral pivoting allows the exfiltration of Kubelet tokens, cloud IAM metadata, and application secrets.

Defensive Implications and Strategic Mitigations

Chaining an application-layer bypass (React2Shell) with shared-kernel vulnerabilities (Copy Fail) illustrates how attacks can traverse multiple trust boundaries. Kubernetes provides strong workload isolation by design, however containers ultimately rely on the security of the shared host kernel. As several copy-on-write (COW) vulnerabilities have demonstrated this year, new privilege-escalation techniques continue to emerge, reinforcing that secure architecture alone is not sufficient. Defending Kubernetes requires a layered strategy that combines sound workload isolation, least-privilege design, timely kernel remediation, and runtime detection to reduce opportunities for application compromise to evolve into host compromise.

• Isolate and Harden Node Kernels: Implement runtime kernel verification tools and apply immediate patches for high-impact local privilege escalations (CVE-2026-31431, CVE-2026-46300). Where feasible, employ container-optimized operating systems that restrict unprivileged user namespaces.
• Enforce Pod Security Standards (PSS): Mitigate the foundational host interaction vectors by enforcing the Restricted pod security profile. Dropping all default Linux capabilities, forcing non-root user execution, and enforcing read-only root filesystems severely inhibits an attacker's ability to manipulate administrative system calls like splice().
• Monitor System Call Anomalies: Establish node-level behavioral baselines for container workloads and identify deviations from expected execution patterns. Monitor for unexpected access to kernel interfaces (such as /dev/kmsg), infrequent or previously unseen kernel log messages, and other anomalous privileged interactions. Because production workloads generally produce repeatable execution and logging patterns, novel or one-time kernel events should be investigated as potential indicators of privilege escalation.
• Minimize Edge Vulnerability Windows: Secure application ingress points through regular dependency audits of Next.js server components and nginx rewrite configurations to block initial foothold attempts before an adversary can establish a local environment to execute kernel primitives.

ExtraHop NDR Detection & Capabilities

Mitigating complex exploit chains requires visibility before host isolation fails. ExtraHop Reveal(x) provides the critical network detection and response (NDR) layer that fills the gaps left by traditional endpoint or container-only security tools.

• Detects Initial Kubernetes Ingress Exploitation: When deployed with ExtraHop supported TLS decryption integrations, Reveal(x) can inspect application-layer traffic for anomalous network behaviors associated with exploitation attempts. NDR analytics can identify suspicious activity surrounding ingress compromise, while enabled IDS detections can provide additional coverage for known exploit signatures, including vulnerabilities such as NGINX Rift (CVE-2026-42945) and React2Shell (CVE-2025-55182).
• Exposes Outbound and East-West Cluster Pivots: When a Kubernetes workload is compromised, Reveal(x) provides visibility into the network behaviors that often accompany post-exploitation activity. By analyzing east-west cluster traffic, the platform can identify anomalous communication patterns, including unexpected connections between application workloads and Kubernetes control-plane services, lateral movement between namespaces, or unusual outbound connections that deviate from established workload baselines. These behaviors can be observed independently of local container telemetry, which may be impaired or manipulated following compromise.
• Bypasses Host Privilege Blind Spots: Kernel-level privilege escalation such as Copy Fail may undermine the reliability of host-resident logs and endpoint telemetry by granting attackers control over the operating system. Reveal(x), however, observes network communications independently of the compromised host, providing a separate source of telemetry that can continue to expose attacker behavior before, during, and after privilege escalation. This independent vantage point complements host-based security controls and helps preserve visibility when local telemetry can no longer be fully trusted.

Resources

• ExtraHop: CVE-2025-55182: How ExtraHop Detects React2Shell RCE Exploits
• ExtraHop: The Copy Fail: Linux Kernel Local Privilege Escalation
• Github Percivallll: Copy Fail CVE 2026-31431 Kubernetes PoC
• Help Net Security: Fragnesia: New Linux kernel LPE bug was spawned by Dirty Frag patch (CVE-2026-46300)
• Huntress: Panic at the Distro
• Kubernetes: Kubernetes Ingress Documentation
• Microsoft: Active attack: Dirty Frag Linux vulnerability expands post-compromise risk
• NEXT.js: https://nextjs.org/docs/app/api-reference/file-conventions/route
• Xint.io: Copy Fail: 732 Bytes to Root on Every Major Linux Distribution.

[1] A route.ts file defines a server-side API endpoint within TypeScript web frameworks (such as Next.js) that executes code directly inside the application's container. In this simulation, it serves as the network-accessible entry point through which the React2Shell payload is processed to trigger the shell.

[2] Amazon Elastic Kubernetes Service