# We Tested Dirty Frag in Kubernetes: EKS and GKE Were Exploitable When Seccomp Was Unset > Canonical: https://juliet.sh/blog/we-tested-dirty-frag-in-kubernetes-eks-gke-talos-seccomp > Published: 2026-05-08 > Author: Juliet Security Team > Tags: kubernetes-security, linux-kernel, seccomp, runtime-security, dirty-frag, cve-2026-43284, pod-security-standards, gke, eks, talos > Read time: 15 min read _We tested Dirty Frag on EKS, GKE, Talos, and kind. EKS and GKE reached container root when seccomp was unset or Unconfined; RuntimeDefault blocked the tested xfrm chain; PSS Restricted blocked the full PoC on GKE and blocked tested prerequisites on EKS and Talos; and Talos blocked Unconfined because user namespaces were disabled._ --- Dirty Frag is a Linux local privilege escalation technique published by Hyunwoo Kim as a public proof of concept in [V4bel/dirtyfrag](https://github.com/V4bel/dirtyfrag). The upstream write-up describes two page-cache write paths: an xfrm-ESP path and an RxRPC path. The xfrm path needs user and network namespace creation. The RxRPC path is meant to cover environments where that namespace path is blocked, but it depends on RxRPC being available. The upstream write-up is Linux-focused. For Kubernetes, the question we cared about was narrower: From an ordinary pod, which parts of the Dirty Frag chain are reachable, and which Kubernetes or node controls actually stop it? We tested that on real Kubernetes clusters and a local kind cluster. The provider differences mattered: - EKS on Amazon Linux 2023: exploitable in our lab when seccomp was unset or `Unconfined`. - GKE on Container-Optimized OS: exploitable in our lab when seccomp was unset or `Unconfined`. - Talos on our on-prem lab cluster: blocked the tested xfrm chain even with explicit `Unconfined` seccomp because user namespaces were disabled at the node level. - `RuntimeDefault` seccomp blocked the tested xfrm chain on EKS, GKE, Talos, and local kind by denying `unshare(USER|NET)`. - Pod Security Standards Restricted blocked the full tested xfrm PoC on GKE and blocked the tested xfrm prerequisites on EKS and Talos. This post is deliberately scoped. We proved container root in controlled pods on EKS and GKE. We did not prove host root. We did not prove a container escape. We did not test every managed Kubernetes distribution, every node image, every kernel build, or the RxRPC fallback end-to-end. `AF_RXRPC` was unsupported in every Kubernetes environment we tested. **Update, May 8, 2026, 13:15 UTC:** Upstream now says the xfrm-ESP Page-Cache Write path has been assigned `CVE-2026-43284` and patched in mainline Linux at commit `f4c50a4034e6`. NVD has also received `CVE-2026-43284` with stable backport references. Upstream says the RxRPC Page-Cache Write path is reserved as `CVE-2026-43500` for tracking, but NVD did not have a public record for that ID as of our 13:03 UTC recheck. Our Kubernetes lab results below cover the xfrm path. We did not validate the RxRPC fallback. **Update, May 8, 2026, 17:45 UTC:** AWS has now published a Dirty Frag bulletin for Amazon Linux kernels. The Amazon Linux CVE page lists Amazon Linux 2023 `kernel`, `kernel6.12`, and `kernel6.18` as `Pending Fix`. AWS says to check whether `esp4`, `esp6`, `ipcomp4`, `ipcomp6`, or `rxrpc` are loaded, and to block future module loading or disable unprivileged user namespaces where that fits the workload. The latest EKS-optimized AL2023 AMI release we found, `v20260505`, uses `kernel6.12 6.12.80-106.156.amzn2023` and `containerd 2.2.3`; our EKS lab below used the older `20260413` image with `6.12.79-101.147.amzn2023` and `containerd 2.2.1`. We have not retested EKS `v20260505`. If a current node shows these modules are not loaded, treat that as an important runtime fact, not as proof that the node is patched or that future module autoloading is impossible. **Update, May 8, 2026, 22:20 UTC:** Distro tracking for the RxRPC side has moved. NVD still had no public `CVE-2026-43500` record at our recheck, but Ubuntu and Debian now publish `CVE-2026-43500` pages for the RxRPC issue. Debian's `DSA-6253-1` includes both `CVE-2026-43284` and `CVE-2026-43500` and fixes Debian trixie in `linux` `6.12.86-1`; `DLA-4572-1` fixes Debian bullseye security in `linux` `5.10.251-4`. This does not change our Kubernetes result below: `AF_RXRPC` was unavailable in the clusters we tested, and we did not validate the RxRPC fallback. **Update, May 9, 2026, 13:25 UTC:** Amazon Linux has moved `CVE-2026-43284` from `Pending Fix` to `Fixed` for Amazon Linux 2023 `kernel`, `kernel6.12`, and `kernel6.18`. The AL2023 `kernel6.12` fix is `ALAS2023-2026-1695`, with package `kernel6.12-6.12.83-113.160.amzn2023`. The latest EKS-optimized AL2023 AMI release we found is still `v20260505`, which lists `kernel6.12 6.12.80-106.156.amzn2023`, so do not treat the Amazon Linux package fix as proof that a managed EKS node image already contains it. Debian also added `DSA-6258-1`, fixing bookworm security in `linux` `6.1.170-3` for both Dirty Frag CVEs. NVD still had no public `CVE-2026-43500` record at this recheck. ## Key findings - On EKS and GKE, pods with unset seccomp ran with `Seccomp: 0`. The xfrm Dirty Frag path worked and reached container `uid=0(root)`. - On EKS and GKE, explicit `seccompProfile.type: Unconfined` also worked and reached container `uid=0(root)`. - On EKS and GKE, `RuntimeDefault` seccomp blocked the PoC at `unshare(USER|NET)` before the page-cache marker changed. - On GKE, PSS Restricted blocked the full PoC with `NoNewPrivs: 1`, `Seccomp: 2`, dropped capabilities, denied `unshare`, and unchanged `/usr/bin/su` marker bytes. On EKS and Talos, PSS Restricted blocked the tested xfrm prerequisites at the same `unshare(USER|NET)` step. - On Talos, `user.max_user_namespaces=0` blocked the xfrm path even when seccomp was explicitly `Unconfined`. - `AF_RXRPC` was not available in our kind, EKS, GKE, or Talos tests, so we do not claim coverage of the RxRPC fallback. - GKE and Talos did not have `pcbc(fcrypt)` available in our tested pods. The xfrm path still succeeded on GKE when seccomp was unset or `Unconfined`, so missing `pcbc(fcrypt)` did not save that GKE node from the xfrm chain. - We saw an important Kubernetes portability difference: on EKS and GKE, leaving seccomp unset meant `Seccomp: 0`; on Talos, an unset seccomp pod still showed `Seccomp: 2` in our test. ## What Dirty Frag is The upstream Dirty Frag project describes a local privilege escalation class built from page-cache write primitives. Its README says the xfrm-ESP page-cache write path has existed since a Linux commit from January 2017, and that the RxRPC path has existed since a June 2023 commit. The author frames Dirty Frag as related to Dirty Pipe and Copy Fail because the attacker changes file-backed page-cache contents rather than ordinary on-disk file bytes. The xfrm path in the public PoC uses user and network namespaces, configures xfrm state through `NETLINK_XFRM`, and patches cached bytes for `/usr/bin/su`. In our successful EKS and GKE lab runs, the pod started as uid 1000, mutated cached bytes for `/usr/bin/su`, then executed the mutated path and reached uid 0 inside the container. That last sentence has a boundary: container uid 0 is not the same claim as host root. Kubernetes pods share the node kernel, but a container process still runs with container namespaces, mounts, and whatever runtime isolation remains. ## Why Kubernetes changes the question Kubernetes teams do not only need to ask "is the Linux kernel affected?" They need to ask: - Can a pod create user and network namespaces? - Is seccomp actually applied? - Is seccomp unset, `RuntimeDefault`, `Localhost`, or `Unconfined`? - Does the node allow unprivileged user namespaces? - Does the kernel expose `NETLINK_XFRM`, `AF_ALG`, and `AF_RXRPC`? - Does PSS Restricted apply to the namespace? - Are untrusted workloads colocated with sensitive pods on the same node? Kubernetes documents seccomp as a way to restrict syscalls from userspace into the kernel. Kubernetes also supports the `RuntimeDefault` profile and node-local `Localhost` profiles. But `RuntimeDefault` is not a single universal profile. It is the default profile provided by the runtime and node environment. Pod Security Standards Restricted is also not a blanket exploit shield. It is a baseline. It requires controls that matter here, including no privilege escalation, seccomp, and dropping all capabilities. Kubernetes says Restricted containers must drop `ALL` capabilities and may only add back `NET_BIND_SERVICE`. In our GKE restricted full-PoC run, that produced `CapBnd: 0000000000000000`, `NoNewPrivs: 1`, and `Seccomp: 2`. For Dirty Frag's xfrm path, those controls were enough in our tests. That is different from our Copy Fail result, where PSS Restricted and `RuntimeDefault` did not block AF_ALG reachability. Dirty Frag and Copy Fail touch related page-cache territory, but their Kubernetes control points are not identical. ## What we tested We used the public Dirty Frag PoC from upstream commit: `892d9a31d391b7f0fccb333855f6289507186748 ` We checked that commit against upstream `master` before writing this post. We built two amd64 binaries for the Kubernetes tests: - A probe binary that records kernel/runtime facts and tests reachability of `AF_RXRPC`, `NETLINK_XFRM`, `AF_ALG`, `pcbc(fcrypt)`, keyring calls, `unshare(USER|NET)`, uid/gid map writes, loopback setup, and `NETLINK_XFRM` after unshare. - A PoC binary based on the public `exp.c`, forced down the xfrm/ESP path, with logging around `/usr/bin/su` marker bytes before and after execution. Every mutating provider run used a privileged cleanup pod to drop page cache before exploit attempts and again at the end. We targeted low-density nodes where possible, used short-lived namespaces with `jdfrag-*` names, and verified deletion afterward. The main success marker was not just "the process exited zero." We required all of the following for an exploitable result: - initial pod uid was non-root; - seccomp state matched the case being tested; - marker bytes in `/usr/bin/su` changed from `0300000004000000` to `31ff31f631c0b06a`; - the PoC printed the xfrm page-cache patch message; - the shell reached `uid=0(root)`; - final cleanup ran. ## EKS result: exploitable when seccomp was unset or Unconfined The EKS run used a non-production cluster. The target node was a low-density Amazon Linux 2023 worker with seven pods during inventory. `Kubernetes: v1.34.7-eks-40737a8 OS image: Amazon Linux 2023.11.20260413 Kernel: 6.12.79-101.147.amzn2023.x86_64 Container runtime: containerd 2.2.1 ` ### EKS RuntimeDefault `RuntimeDefault` blocked the xfrm chain at namespace creation: `NoNewPrivs: 0 Seccomp: 2 Seccomp_filters: 1 DIRTYFRAG_EXP_BEFORE_MARKER 0300000004000000 [su] unshare: Operation not permitted dirtyfrag: failed (rc=1) DIRTYFRAG_EXP_AFTER_MARKER 0300000004000000 ` The probe showed that `NETLINK_XFRM` and `AF_ALG` were reachable before unshare, and `pcbc(fcrypt)` existed on this EKS node, but `unshare(USER|NET)` was denied. For the xfrm chain, that denial was decisive. ### EKS unset seccomp With no seccomp profile set, the pod ran with `Seccomp: 0`. The probe showed `unshare(USER|NET)` succeeded, uid/gid maps could be written, loopback could be brought up, and `NETLINK_XFRM` worked after unshare. The full PoC reached container root: `DIRTYFRAG_IDS_BEFORE uid=1000 gid=1000 groups=1000 CapEff: 0000000000000000 NoNewPrivs: 0 Seccomp: 0 Seccomp_filters: 0 DIRTYFRAG_EXP_BEFORE_MARKER 0300000004000000 [su] installed 48 xfrm SAs [su] wrote 192 bytes to /usr/bin/su starting at 0x0 [su] /usr/bin/su page-cache patched (entry 0x78 = shellcode) # uid=0(root) gid=0(root) groups=0(root) root DIRTYFRAG_EXP_AFTER_MARKER 31ff31f631c0b06a ` ### EKS Unconfined Explicit `seccompProfile.type: Unconfined` also reached container root with the same marker change and `uid=0(root)` result. ### EKS PSS Restricted The EKS restricted probe had `NoNewPrivs: 1`, `Seccomp: 2`, no effective capabilities, and denied `unshare(USER|NET)`. We did not run the full mutating PoC in the EKS restricted namespace after the GKE restricted full-PoC confirmed the same failure point. The validated EKS claim is narrower: PSS Restricted blocked the prerequisites we tested for the xfrm path. ## GKE result: exploitable when seccomp was unset or Unconfined The GKE run used a dev/staging cluster. The target node was the lowest-density Container-Optimized OS worker during inventory. `Kubernetes: v1.33.9-gke.1060000 OS image: Container-Optimized OS from Google Kernel: 6.6.122+ Container runtime: containerd 2.0.7 ` ### GKE RuntimeDefault `RuntimeDefault` blocked the xfrm chain at `unshare(USER|NET)`: `NoNewPrivs: 0 Seccomp: 2 Seccomp_filters: 1 DIRTYFRAG_EXP_BEFORE_MARKER 0300000004000000 [su] unshare: Operation not permitted dirtyfrag: failed (rc=1) DIRTYFRAG_EXP_AFTER_MARKER 0300000004000000 ` ### GKE unset seccomp Unset seccomp on GKE behaved like EKS: the pod ran with `Seccomp: 0`, user and network namespace creation worked, and `NETLINK_XFRM` worked after unshare. The full PoC reached container root: `DIRTYFRAG_IDS_BEFORE uid=1000 gid=1000 groups=1000 CapEff: 0000000000000000 NoNewPrivs: 0 Seccomp: 0 Seccomp_filters: 0 DIRTYFRAG_EXP_BEFORE_MARKER 0300000004000000 [su] installed 48 xfrm SAs [su] wrote 192 bytes to /usr/bin/su starting at 0x0 [su] /usr/bin/su page-cache patched (entry 0x78 = shellcode) # uid=0(root) gid=0(root) groups=0(root) root DIRTYFRAG_EXP_AFTER_MARKER 31ff31f631c0b06a ` ### GKE Unconfined Explicit `Unconfined` also reached container root. The result matched the unset seccomp case: marker changed to `31ff31f631c0b06a`, and the PoC reached `uid=0(root)`. ### GKE PSS Restricted We ran the full PoC in a PSS Restricted namespace. It failed before the page-cache marker changed: `DIRTYFRAG_IDS_BEFORE uid=1000 gid=1000 groups=1000 CapEff: 0000000000000000 CapBnd: 0000000000000000 NoNewPrivs: 1 Seccomp: 2 Seccomp_filters: 1 DIRTYFRAG_EXP_BEFORE_MARKER 0300000004000000 [su] unshare: Operation not permitted dirtyfrag: failed (rc=1) DIRTYFRAG_EXP_AFTER_MARKER 0300000004000000 ` That was the most direct defense result in the set: PSS Restricted blocked the full tested xfrm chain on GKE. ## Talos result: blocked by user namespaces disabled The on-prem lab cluster includes Talos and non-Talos nodes. For the final Talos pass, we targeted a Talos worker with user namespaces disabled. `Kubernetes: v1.35.0 OS image: Talos v1.12.2 Kernel: 6.18.5-talos Container runtime: containerd 2.1.6 ` `RuntimeDefault` and the unset-seccomp case both showed `Seccomp: 2` in our Talos run and denied `unshare(USER|NET)` with `EPERM`. The more interesting case was explicit `Unconfined`: `DIRTYFRAG_PROBE status Seccomp: 0 DIRTYFRAG_PROBE proc max_user_namespaces 0 DIRTYFRAG_PROBE socket(NETLINK_XFRM) OK DIRTYFRAG_PROBE socket(AF_ALG) OK DIRTYFRAG_PROBE unshare(USER|NET) ERR errno=28 (No space left on device) ` The full PoC under explicit `Unconfined` failed the same way: `NoNewPrivs: 0 Seccomp: 0 DIRTYFRAG_EXP_BEFORE_MARKER 0300000004000000 [su] unshare: No space left on device dirtyfrag: failed (rc=1) DIRTYFRAG_EXP_AFTER_MARKER 0300000004000000 ` `user.max_user_namespaces=0` was enough to stop the tested xfrm path on this Talos node. That does not mean "Talos is immune to Dirty Frag." It means this specific Dirty Frag xfrm chain could not pass the namespace setup step in our Talos configuration. ## Local kind result We also ran a local kind cluster on an arm64 OrbStack host. It was useful for control testing but not central to our provider claims. In a permissive local kind setup, the xfrm path changed the `/usr/bin/su` marker bytes. It did not hand off cleanly to root because the upstream payload path we used was x86_64 and the host was arm64. In `RuntimeDefault` and PSS Restricted cases, the chain failed at `unshare(USER|NET)`. We are not using kind as evidence for cloud-provider exposure. It was a reproducibility harness and a guardrail against confusing Kubernetes YAML behavior with provider behavior. ## Why unset seccomp is the Kubernetes footgun Operationally, the key finding was that unset seccomp was not equivalent to `RuntimeDefault` in EKS or GKE. On both providers: - unset seccomp: `Seccomp: 0`, xfrm chain succeeded, container root reached; - `RuntimeDefault`: `Seccomp: 2`, `unshare(USER|NET)` denied, marker unchanged; - `Unconfined`: `Seccomp: 0`, xfrm chain succeeded, container root reached. Teams often check for `Unconfined` and miss unset seccomp. For Dirty Frag's xfrm path, that distinction was the difference between blocked and exploitable in our EKS and GKE labs. ## Controls that changed the lab result ### Enforce seccomp, do not leave it unset For the xfrm chain we tested, `RuntimeDefault` was enough to block `unshare(USER|NET)` in EKS, GKE, Talos, and kind. That does not make `RuntimeDefault` a universal Dirty Frag fix. It means the tested runtime default profiles blocked the tested xfrm path. If a different runtime default allows user and network namespace creation, your result may differ. For high-risk workloads, consider a known-good `Localhost` seccomp profile and test it on every node family. Kubernetes supports applying node-local seccomp profiles to pods, but the profile must exist on the node and the workload has to reference it correctly. ### Enforce PSS Restricted for untrusted workloads PSS Restricted blocked the full tested xfrm chain on GKE and blocked the tested prerequisites on EKS and Talos. The relevant controls are: - `allowPrivilegeEscalation: false`, which sets `no_new_privs`; - `seccompProfile.type: RuntimeDefault` or a restrictive `Localhost` profile; - `capabilities.drop: ["ALL"]`; - non-root execution. PSS Restricted is not a substitute for patching the kernel, but it changed the outcome of this PoC. ### Consider node-level user namespace restrictions Talos blocked the xfrm path even under explicit `Unconfined` seccomp because `user.max_user_namespaces=0`. This is a strong control for this chain, but it can break workloads that legitimately need unprivileged user namespaces. Treat it as a node-pool decision, not a casual cluster-wide toggle. Build runners, image builders, sandboxing tools, and some developer workloads may depend on user namespaces. ### Watch for unset or Unconfined seccomp as a high-priority posture issue For Dirty Frag, a pod with unset seccomp on EKS or GKE was not merely "less hardened." It was exploitable in our lab. Inventory all running pods and flag: - unset seccomp at pod and container level; - `seccompProfile.type: Unconfined`; - namespaces without PSS labels; - `allowPrivilegeEscalation: true` or unset; - containers that do not drop all capabilities; - workloads on node pools that allow unprivileged user namespaces. ### Patch and replace nodes as vendor guidance lands Dirty Frag is a Linux kernel issue. Kubernetes policy can reduce exploitability, but the durable fix is at the node OS/kernel layer. For the xfrm path we tested, track `CVE-2026-43284` and your node OS vendor's kernel packages. Upstream Linux and stable references now exist, but managed Kubernetes nodes are only fixed when the node image or kernel package you are actually running includes the backport. Kernel strings can be misleading because vendors backport fixes without changing to the same upstream version number. For EKS on Amazon Linux, also track AWS Security Bulletin `2026-027-AWS` and the Amazon Linux CVE status. At our 17:35 UTC recheck on May 8, 2026, Amazon Linux still showed AL2023 `kernel6.12` as `Pending Fix`, even though the latest EKS-optimized AL2023 AMI release had moved from the kernel we tested to `6.12.80-106.156.amzn2023`. At our 13:25 UTC recheck on May 9, 2026, Amazon Linux had published AL2023 fixes for `CVE-2026-43284`: `ALAS2023-2026-1694` for `kernel`, `ALAS2023-2026-1695` for `kernel6.12`, and `ALAS2023-2026-1693` for `kernel6.18`. EKS node image status is a separate question from Amazon Linux package availability. As of that same recheck, the latest EKS-optimized AL2023 AMI release was still `v20260505`, with `kernel6.12 6.12.80-106.156.amzn2023`, not the fixed `kernel6.12-6.12.83-113.160.amzn2023` package. Module state is worth checking, but it needs careful interpretation. AWS recommends checking `lsmod` for `esp4`, `esp6`, `ipcomp4`, `ipcomp6`, and `rxrpc`; if the modules are not loaded, AWS still recommends blocking future module loading where appropriate. In other words, "not loaded right now" is not the same evidence as "patched," and it is not the same evidence as "cannot be loaded by a reachable kernel path." Treat RxRPC separately. Upstream says `CVE-2026-43500` is reserved for tracking the RxRPC Page-Cache Write path. Debian and Ubuntu now publish downstream `CVE-2026-43500` records, and Debian has shipped `linux` package fixes for bullseye security, bookworm security, and trixie security. We still did not test that path and did not see `AF_RXRPC` available in any Kubernetes environment we tested. ## What Juliet can do here This is where a graph view helps: the answer lives across node inventory, workload posture, and runtime facts. For Dirty Frag exposure, the useful graph is: - node kernel, OS image, Kubernetes version, and container runtime; - workload-to-node placement; - effective seccomp after pod-level and container-level inheritance; - PSS labels on namespaces; - `allowPrivilegeEscalation`, capabilities, privileged mode, host namespaces, and hostPath; - node facts such as `user.max_user_namespaces` and whether tested address families are reachable. Juliet can turn that into the questions defenders need to answer: - Which workloads are running with unset or `Unconfined` seccomp on EKS or GKE? - Which namespaces are not enforcing PSS Restricted? - Which high-risk workloads share nodes with sensitive workloads? - Which node families need a targeted Dirty Frag validation run? - Which compensating controls are present, and which ones are not changing the risk? Juliet can also help block the risky paths we validated: - Admission policies can reject new workloads that leave seccomp unset, use `Unconfined`, allow privilege escalation, or fail to drop all capabilities. - Kubernetes PSS Restricted enforcement can be rolled out namespace by namespace while Juliet monitors namespace labels and workload posture, so teams can see which workloads would break before switching from audit to enforce. - Runtime policies can detect namespace-manipulation attempts such as `unshare` and `setns`; in enforce mode, Juliet can kill matching container processes with namespace scope and rate-limit guardrails. That is not the same as claiming Juliet patches the kernel. The safest control stack is still: patch or replace affected nodes, enforce seccomp/PSS for untrusted workloads, and use runtime enforcement as an additional tripwire for exploit behavior. **Want help checking this in your clusters?** [Start Juliet free](https://app.juliet.sh/register?plan=starter), connect a non-production cluster first, and use Explorer to inspect seccomp posture, namespace PSS labels, workload placement, and node facts. If you want us to run this with you, [request a Dirty Frag exposure review](mailto:contact@juliet.sh?subject=Dirty%20Frag%20Kubernetes%20exposure%20review). ## What we did not prove Do not overread this post. We did not prove that every EKS cluster is exploitable. We tested one EKS cluster, one Amazon Linux 2023 node family, one kernel build, and one containerd build. We did not prove that every GKE cluster is exploitable. We tested one GKE cluster, one COS node family, one kernel build, and one containerd build. We did not prove that Talos universally blocks Dirty Frag. We proved that our Talos node, with `user.max_user_namespaces=0`, blocked the tested xfrm path. We did not prove host root, node persistence, or container escape. We did not test the RxRPC fallback end-to-end because `AF_RXRPC` was unsupported in every environment we tested. We are not publishing exploit code, lab patches, or reproduction commands in this post. ## Defender checklist Immediate checks: - Find pods where effective seccomp is unset or `Unconfined`. - Enforce `RuntimeDefault` or a known-good `Localhost` seccomp profile for untrusted workloads. - Enforce PSS Restricted on namespaces that run untrusted or multi-tenant workloads. - Confirm `allowPrivilegeEscalation: false` and `capabilities.drop: ["ALL"]`. - Check node-level user namespace policy on each node pool. - On Amazon Linux nodes, check whether AWS-listed modules are loaded and whether future loading is blocked where appropriate. - Separate build runners, CI jobs, plugin execution, and customer-controlled code from sensitive workloads. - Track `CVE-2026-43284` vendor kernel guidance and plan node replacement or patch rollout. Validation checks: - Do not assume YAML intent equals runtime behavior. Inspect `/proc/self/status` inside a test pod and confirm `Seccomp`. - Test representative node pools separately. EKS, GKE, Talos, and kind did not behave identically. - Confirm cleanup and node health after any authorized validation run. - Treat `AF_RXRPC` separately. We could not test that fallback because it was not available in our environments. ## FAQ ### Is Dirty Frag a Kubernetes vulnerability? No. It is a Linux kernel issue. Kubernetes matters because pods share the node kernel, and Kubernetes policy determines whether a pod can reach the primitives the exploit chain needs. ### Does RuntimeDefault stop Dirty Frag? It stopped the tested xfrm path in our EKS, GKE, Talos, and kind labs by denying `unshare(USER|NET)`. Do not generalize that to every runtime or every future Dirty Frag variant without testing. ### Does PSS Restricted stop Dirty Frag? It blocked the tested xfrm chain in our labs. On GKE, we ran the full PoC under PSS Restricted and it failed before marker bytes changed. On EKS and Talos, Restricted blocked the tested prerequisites, including `unshare(USER|NET)`. ### Were EKS and GKE exploitable? In our labs, yes, when seccomp was unset or explicitly `Unconfined`. The result was container root inside the pod, not proven host root. ### Was Talos exploitable? Not in our final Talos xfrm test. Explicit `Unconfined` seccomp produced `Seccomp: 0`, but `user.max_user_namespaces=0` caused `unshare(USER|NET)` to fail with `ENOSPC`. ### What is the most important thing to check first? Find pods with unset or `Unconfined` seccomp on node pools that allow user namespaces. That was the strongest predictor of exploitability in the EKS and GKE tests. ## Sources - [V4bel/dirtyfrag upstream repository](https://github.com/V4bel/dirtyfrag) - [Dirty Frag upstream technical write-up](https://github.com/V4bel/dirtyfrag/blob/master/assets/write-up.md) - [Linux mainline xfrm-ESP fix `f4c50a4034e6`](https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=f4c50a4034e62ab75f1d5cdd191dd5f9c77fdff4) - [NVD CVE-2026-43284](https://nvd.nist.gov/vuln/detail/CVE-2026-43284) - [NVD CVE-2026-43500](https://nvd.nist.gov/vuln/detail/CVE-2026-43500) - [AWS Security Bulletin 2026-027-AWS: Dirty Frag and other issues in Amazon Linux kernels](https://aws.amazon.com/security/security-bulletins/rss/2026-027-aws/) - [Amazon Linux CVE-2026-43284 status](https://explore.alas.aws.amazon.com/CVE-2026-43284.html) - [Amazon Linux ALAS2023-2026-1694: AL2023 kernel](https://alas.aws.amazon.com/AL2023/ALAS2023-2026-1694.html) - [Amazon Linux ALAS2023-2026-1695: AL2023 kernel6.12](https://alas.aws.amazon.com/AL2023/ALAS2023-2026-1695.html) - [Amazon Linux ALAS2023-2026-1693: AL2023 kernel6.18](https://alas.aws.amazon.com/AL2023/ALAS2023-2026-1693.html) - [Amazon EKS optimized AMI release `v20260505`](https://github.com/awslabs/amazon-eks-ami/releases/tag/v20260505) - [Red Hat CVE-2026-43284](https://access.redhat.com/security/cve/CVE-2026-43284) - [Ubuntu CVE-2026-43500](https://ubuntu.com/security/CVE-2026-43500) - [Ubuntu Dirty Frag mitigation post](https://ubuntu.com/blog/dirty-frag-linux-vulnerability-fixes-available) - [Debian CVE-2026-43500](https://security-tracker.debian.org/tracker/CVE-2026-43500) - [Debian DSA-6253-1](https://security-tracker.debian.org/tracker/DSA-6253-1) - [Debian DSA-6258-1](https://security-tracker.debian.org/tracker/DSA-6258-1) - [Debian DLA-4572-1](https://security-tracker.debian.org/tracker/DLA-4572-1) - [Kubernetes Pod Security Standards](https://kubernetes.io/docs/concepts/security/pod-security-standards/) - [Kubernetes seccomp documentation](https://kubernetes.io/docs/tutorials/security/seccomp/)