Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹 Go

GHSA-m38g-vww2-mvgx

HIGH

Talos Linux has a local privilege escalation from untrusted workloads

Published
May 7, 2026
Updated
Jun 9, 2026
Affected
1 pkg
Patched
1 / 1
Exploits
None indexed

Blast Radius

1 pkg affected
🐹github.com/siderolabs/talos

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Summary

A vulnerability in the Linux kernel's algif_aead subsystem (CVE-2026-31431, "copy.fail") allows an unprivileged container workload to corrupt arbitrary file page-cache pages via the AF_ALG crypto interface and splice(). On Talos Linux, this vulnerability can be chained into a complete node compromise: an attacker who can schedule a pod on a worker node can, without any elevated Kubernetes permissions, achieve arbitrary code execution as root on the host (by poisoning a binary inside a privileged pod, or poisoning a binary which runs with elevated privileges like a CNI binary), access host filesystem, including node secrets.

The exploit does not require kernel debugging, race conditions, or any prior privileges beyond the ability to create a pod.

Impact

An attacker with the ability to deploy a Kubernetes pod on an affected node can:

  1. Corrupt the page-cache of /usr/sbin/nft in the containerd snapshot layer shared between the attacker's pod and the kube-proxy DaemonSet. Because containerd reuses XFS page-cache pages across overlayfs mounts sharing the same lower layer, the corruption is immediately visible to all containers using that image layer — including privileged system DaemonSets.
  2. Execute arbitrary code inside kube-proxy — a privileged DaemonSet running on every node with all Linux capabilities (privileged: true) and host network access — the next time kube-proxy invokes nft as part of its nftables reconciliation loop (typically within seconds).
  3. At this point, an attacker achieved code execution inside a privileged pod, which allows to escape to the host.
  4. Same attack can be planted by infiltrating other binaries running as privileged, for example a CNI plugin.

Patches

Upgrade to Talos v1.13.0 or Talos v1.12.7 which ships Linux kernel 6.18.25. The kernel fix for CVE-2026-31431 (algif_aead in-place optimization revert) was committed upstream in Linux 6.18.22 and is included in all Talos releases from v1.13.0 and Talos 1.12.7 onwards.

Workarounds

There are multiple workarounds available based on the situation, but we really recommend to upgrade.

Option 1 - Change kernel arguments

Add a kernel argument with initcall_blacklist=algif_aead_init by upgrading Talos to the same version.

Note: this either requires setting machine.kernel.extraKernelArgs if using BIOS based boot or upgrading with a new image from factory/imager generated image by setting the extra kernel args. See Boot Assets

Option 2 - Deploy all workload pods with a seccomp profile denying creating AF_ALG socket creation

patch.yaml

machine:
  seccompProfiles:
    - name: copy-fail-block.json
      value:
        defaultAction: SCMP_ACT_ALLOW
        syscalls:
          - names:
              - socket
            action: SCMP_ACT_ERRNO
            args:
              - index: 0
                value: 38
                op: SCMP_CMP_EQ

Apply this patch to all machines in the cluster and set this for all the pod spec:

...
spec:
      securityContext:
        seccompProfile:
          type: Localhost
          localhostProfile: profiles/copy-fail-block.json

Option 3 - Block the syscall in runtime with a eBPF program

See copy-fail-blocker, this can be applied to a running system without a reboot, but it has to run before any other workloads are scheduled after a reboot.

References

Affected Packages

1 total 1 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/siderolabs/talosall versions1.12.7

Detection & mitigation playbook

Open-source dependency

  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/siderolabs/talos. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.

  2. Fix

    Update github.com/siderolabs/talos to 1.12.7 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-m38g-vww2-mvgx is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 pinpoints whether GHSA-m38g-vww2-mvgx is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.

Tailored to GHSA-m38g-vww2-mvgx. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

### Summary A vulnerability in the Linux kernel's algif_aead subsystem (CVE-2026-31431, "copy.fail") allows an unprivileged container workload to corrupt arbitrary file page-cache pages via the AF_ALG crypto interface and splice(). On Talos Linux, this vulnerability can be chained into a complete node compromise: an attacker who can schedule a pod on a worker node can, without any elevated Kubernetes permissions, achieve arbitrary code execution as root on the host (by poisoning a binary inside a privileged pod, or poisoning a binary which runs with elevated privileges like a CNI binary), acc
O3 Security · Impact-Aware SCA

Is GHSA-m38g-vww2-mvgx in your dependencies?

O3 detects GHSA-m38g-vww2-mvgx across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.

Scan my dependencies How O3 SCA works