Fragnesia CVE-2026-46300 in Kubernetes: What EKS, Talos, and Seccomp Change

Fragnesia is the new Dirty Frag-family name Kubernetes teams are going to search for, but the practical question is narrower than the headline:

Can an ordinary Kubernetes pod reach the Fragnesia path on the nodes you actually run?

Our answer from fresh lab testing is: not in the Kubernetes environments we checked. We did not reproduce a Fragnesia page-cache mutation in local kind, Talos, or EKS AL2023. That negative result is still useful. It shows which gates defenders should inventory before treating CVE-2026-46300 as either exploitable or irrelevant in a cluster.

This is not a claim that every Kubernetes node is safe. It is a scoped result from one local kind environment, one Talos lab node, and two EKS AL2023 node builds. We are also not publishing exploit code, reproduction commands, or lab patches here.

What Fragnesia is

The upstream Fragnesia write-up from V12 describes it as a separate bug in the Dirty Frag class, in the Linux XFRM ESP-in-TCP subsystem. Red Hat tracks it as CVE-2026-46300 alongside the original ESP/XFRM Dirty Frag issue, CVE-2026-43284, and the RxRPC issue, CVE-2026-43500.

The important Kubernetes distinction is that Fragnesia is not just "the same Dirty Frag test again." The original xfrm-ESP path we reproduced earlier depended on user and network namespace creation plus XFRM/ESP reachability. Fragnesia adds a different kernel surface: ESP-in-TCP.

That means a Kubernetes answer has at least four layers:

• workload posture: seccomp, PSS, capabilities, and privilege escalation settings;
• node policy: whether unprivileged user namespaces are allowed;
• kernel surface: whether XFRM/ESP and ESP-in-TCP are present and reachable;
• patch state: whether your node image or kernel package includes the relevant backport.

Looking at only one of those layers is how teams get false confidence.

What we tested

We used a defensive harness built from the public Fragnesia research, but we changed the target to a disposable read-only file in an emptyDir volume. We did not target /usr/bin/su, did not hand off to a shell, and did not mutate a shared system binary.

We ran four pod postures:

• unset seccomp;
• explicit seccompProfile.type: Unconfined;
• seccompProfile.type: RuntimeDefault;
• PSS Restricted-style settings with RuntimeDefault, allowPrivilegeEscalation: false, dropped capabilities, and non-root users.

We ran those cases in:

• a local kind cluster;
• a Talos Kubernetes worker;
• EKS on AL2023 6.12.79-101.147.amzn2023;
• EKS on AL2023 6.12.80-106.156.amzn2023.

For EKS, we also mounted host kernel config and module metadata read-only to check whether ESP-in-TCP was built or packaged on the AL2023 nodes we tested.

What happened

RuntimeDefault and PSS Restricted blocked the Fragnesia chain at user namespace creation in every environment where those controls were active. That is consistent with what we saw in our earlier Dirty Frag xfrm testing: seccomp mattered because the chain needed namespace setup before it could configure the relevant networking state.

Talos blocked even earlier. The Talos node we tested had user.max_user_namespaces=0, so the user namespace prerequisite failed. Its host kernel config also had both CONFIG_INET_ESPINTCP and CONFIG_INET6_ESPINTCP unset.

The EKS result was more interesting. In unset and Unconfined pods, the harness could create user and network namespaces and could see ESP/XFRM-related modules such as esp4, esp6, and xfrm_user. But the Fragnesia-specific path still did not reach page-cache mutation. The kernel rejected the ESP-in-TCP setup, and a direct TCP ULP probe returned that espintcp was unavailable. Host config confirmed the reason: both EKS AL2023 node builds we inspected had CONFIG_INET_ESPINTCP and CONFIG_INET6_ESPINTCP unset.

So the short version is:

• unset and Unconfined seccomp were still weaker postures;
• RuntimeDefault and PSS Restricted blocked the user namespace prerequisite;
• Talos also had user namespaces disabled at the node level;
• the EKS AL2023 kernels we checked did not expose ESP-in-TCP;
• we did not observe page-cache mutation in these Kubernetes tests.

What this means for EKS, Talos, and other clusters

Do not translate this into "Fragnesia does not matter in Kubernetes." Translate it into a checklist.

For EKS, the AL2023 nodes we checked had ESP-in-TCP disabled in host kernel config, but that does not prove every EKS node image, custom AMI, Bottlerocket variant, Ubuntu node group, or future kernel stream has the same shape. If you run mixed node groups, inspect each family separately.

For Talos, our lab node had two useful gates: user.max_user_namespaces=0 and ESP-in-TCP disabled in kernel config. That is a strong result for that node, not a universal statement about every Talos version or extension set.

For OpenShift and Red Hat environments, follow Red Hat's Dirty Frag bulletin. Red Hat explicitly groups Fragnesia into the Dirty Frag set and says existing mitigations are believed to apply while validation continues.

For Ubuntu and Debian, track their CVE-2026-46300 status pages. Ubuntu currently describes Fragnesia as a high-priority local privilege escalation issue, and Debian tracking lists checked Linux streams as vulnerable at the time of this writing.

Defender checklist

Start with workload posture:

• Find pods where seccomp is unset or Unconfined.
• Enforce RuntimeDefault or stronger local seccomp profiles for untrusted workloads.
• Apply Pod Security Standards Restricted where workloads can tolerate it.
• Check for allowPrivilegeEscalation: true or unset.
• Check containers that do not drop capabilities.

Then inspect node facts:

• Record kernel version, node image, container runtime, and OS family for each node pool.
• Check whether unprivileged user namespaces are allowed.
• Check whether esp4, esp6, and xfrm_user are loaded.
• Check whether future module loading is blocked where your vendor recommends it.
• Check whether CONFIG_INET_ESPINTCP and CONFIG_INET6_ESPINTCP are enabled.
• Verify vendor fixes against the running node image, not only against an advisory page.

Finally, keep the claim boundary clear. Kubernetes policy can reduce exploitability, but the durable fix is still a patched or non-affected node kernel. Conversely, a vulnerable CVE page does not automatically mean your pods can reach the vulnerable path.

Bottom line for Kubernetes defenders

Fragnesia matters to Kubernetes because pods share the node kernel. In our kind, Talos, and EKS AL2023 checks, we did not reproduce page-cache mutation, but exploitability depends on pod posture, user namespace policy, and whether ESP-in-TCP exists in the node kernel.

The most actionable controls were RuntimeDefault/PSS for the namespace prerequisite and direct node-kernel validation for ESP-in-TCP reachability.

That is a useful outcome. It is less dramatic than a successful exploit demo, but it is the kind of result Kubernetes security teams need: a bounded test, a concrete set of gates, and a checklist they can run across real node pools.

References

• V12 Fragnesia proof-of-concept and write-up
• Red Hat RHSB-2026-003 Dirty Frag bulletin
• Ubuntu CVE-2026-46300
• Debian CVE-2026-46300 tracker
• Kubernetes seccomp documentation
• Kubernetes Pod Security Standards
• Our Dirty Frag Kubernetes lab results