github.com/siderolabs/talos

Version	Released
`v1.15.0-alpha.0` pre	Sep 08, 2026
`v1.13.10` patch	Sep 03, 2026
`v1.14.0` minor	Sep 03, 2026
`v1.14.0-rc.2` pre	Aug 25, 2026
`v1.13.9` patch	Aug 18, 2026
`v1.14.0-rc.1` pre	Aug 14, 2026
`v1.13.8` patch	Aug 04, 2026
`v1.14.0-beta.1` pre	Jul 31, 2026
`v1.14.0-beta.0` pre	Jul 23, 2026
`v1.13.7` patch	Jul 21, 2026
`v1.13.6` patch	Jul 09, 2026
`v1.14.0-alpha.2` pre	Jun 26, 2026
`v1.13.5` patch	Jun 22, 2026
`v1.13.4` patch	Jun 09, 2026
`v1.14.0-alpha.1` pre	May 28, 2026
`v1.13.3` patch	May 25, 2026
`v1.13.2` patch	May 12, 2026
`v1.13.1` patch	May 12, 2026
`v1.14.0-alpha.0` pre	Apr 29, 2026
`v1.13.0` minor	Apr 27, 2026
`v1.12.7` minor	Apr 24, 2026
`v1.13.0-rc.0` pre	Apr 16, 2026
`v1.13.0-beta.1` pre	Mar 27, 2026
`v1.13.0-beta.0` pre	Mar 18, 2026
`v1.13.0-alpha.2` pre	Feb 25, 2026
`v1.13.0-alpha.1` pre	Feb 03, 2026
`v1.13.0-alpha.0` pre	Dec 25, 2025
`v1.11.5` patch 1 CVE	Nov 06, 2025
`v1.11.1` minor 1 CVE	Sep 08, 2025
`v1.10.3` minor 1 CVE	May 29, 2025
`v1.9.5` minor 1 CVE	Mar 12, 2025
`v1.8.4` patch 1 CVE	Dec 12, 2024
`v1.9.0-alpha.0` pre 1 CVE	Oct 18, 2024
`v1.8.1` minor 1 CVE	Oct 08, 2024
`v1.8.0-beta.0` pre 1 CVE	Sep 09, 2024
`v1.7.6` patch 1 CVE	Aug 06, 2024
`v1.7.4` minor 1 CVE	May 30, 2024
`v1.6.7` patch 1 CVE	Mar 20, 2024
`v1.7.0-alpha.1` pre 1 CVE	Mar 14, 2024
`v1.6.2` minor 2 CVEs	Jan 18, 2024
`v1.6.0-alpha.1` pre 1 CVE	Oct 17, 2023
`v1.4.8` patch 2 CVEs	Aug 10, 2023
`v1.4.7` minor 2 CVEs	Jul 26, 2023
`v1.3.7` minor 2 CVEs	Apr 06, 2023
`v1.3.0-beta.2` pre 2 CVEs	Dec 09, 2022
`v1.2.0-alpha.0` pre 3 CVEs	Jun 30, 2022
`v1.1.0` minor 3 CVEs	Jun 21, 2022
`v1.0.1` major 3 CVEs	Apr 04, 2022
`v0.14.3` minor 3 CVEs	Mar 03, 2022
`v0.15.0-alpha.0` pre 3 CVEs	Dec 30, 2021

v1.15.0-alpha.0 pre

Sep 08, 2026

v1.13.10 patch

Sep 03, 2026

v1.14.0 minor

Sep 03, 2026

v1.14.0-rc.2 pre

Aug 25, 2026

v1.13.9 patch

Aug 18, 2026

v1.14.0-rc.1 pre

Aug 14, 2026

v1.13.8 patch

Aug 04, 2026

v1.14.0-beta.1 pre

Jul 31, 2026

v1.14.0-beta.0 pre

Jul 23, 2026

v1.13.7 patch

Jul 21, 2026

v1.13.6 patch

Jul 09, 2026

v1.14.0-alpha.2 pre

Jun 26, 2026

v1.13.5 patch

Jun 22, 2026

v1.13.4 patch

Jun 09, 2026

v1.14.0-alpha.1 pre

May 28, 2026

v1.13.3 patch

May 25, 2026

v1.13.2 patch

May 12, 2026

v1.13.1 patch

May 12, 2026

v1.14.0-alpha.0 pre

Apr 29, 2026

v1.13.0 minor

Apr 27, 2026

v1.12.7 minor

Apr 24, 2026

v1.13.0-rc.0 pre

Apr 16, 2026

v1.13.0-beta.1 pre

Mar 27, 2026

v1.13.0-beta.0 pre

Mar 18, 2026

v1.13.0-alpha.2 pre

Feb 25, 2026

v1.13.0-alpha.1 pre

Feb 03, 2026

v1.13.0-alpha.0 pre

Dec 25, 2025

v1.11.5 patch

1 CVE

GHSA-m38g-vww2-mvgx May 07, 2026

Talos Linux has a local privilege escalation from untrusted workloads

7.5 / 10

High

Local High Low None Changed High High None

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:

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.
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).
At this point, an attacker achieved code execution inside a privileged pod, which allows to escape to the host.
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.

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

https://copy.fail/
https://xint.io/blog/copy-fail-linux-distributions
https://github.com/theori-io/copy-fail-CVE-2026-31431
https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC

Fixed in


          1.12.7

References

Updated Jun 09, 2026 · Source: OSV.dev

Nov 06, 2025

v1.11.1 minor

1 CVE

GHSA-m38g-vww2-mvgx May 07, 2026

Talos Linux has a local privilege escalation from untrusted workloads

7.5 / 10

High

Local High Low None Changed High High None

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:

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.
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).
At this point, an attacker achieved code execution inside a privileged pod, which allows to escape to the host.
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.

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

https://copy.fail/
https://xint.io/blog/copy-fail-linux-distributions
https://github.com/theori-io/copy-fail-CVE-2026-31431
https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC

Fixed in


          1.12.7

References

Updated Jun 09, 2026 · Source: OSV.dev

Sep 08, 2025

v1.10.3 minor

1 CVE

GHSA-m38g-vww2-mvgx May 07, 2026

Talos Linux has a local privilege escalation from untrusted workloads

7.5 / 10

High

Local High Low None Changed High High None

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:

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.
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).
At this point, an attacker achieved code execution inside a privileged pod, which allows to escape to the host.
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.

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

https://copy.fail/
https://xint.io/blog/copy-fail-linux-distributions
https://github.com/theori-io/copy-fail-CVE-2026-31431
https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC

Fixed in


          1.12.7

References

Updated Jun 09, 2026 · Source: OSV.dev

May 29, 2025

v1.9.5 minor

1 CVE

GHSA-m38g-vww2-mvgx May 07, 2026

Talos Linux has a local privilege escalation from untrusted workloads

7.5 / 10

High

Local High Low None Changed High High None

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:

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.
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).
At this point, an attacker achieved code execution inside a privileged pod, which allows to escape to the host.
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.

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

https://copy.fail/
https://xint.io/blog/copy-fail-linux-distributions
https://github.com/theori-io/copy-fail-CVE-2026-31431
https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC

Fixed in


          1.12.7

References

Updated Jun 09, 2026 · Source: OSV.dev

Mar 12, 2025

v1.8.4 patch

1 CVE

GHSA-m38g-vww2-mvgx May 07, 2026

Talos Linux has a local privilege escalation from untrusted workloads

7.5 / 10

High

Local High Low None Changed High High None

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:

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.
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).
At this point, an attacker achieved code execution inside a privileged pod, which allows to escape to the host.
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.

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

https://copy.fail/
https://xint.io/blog/copy-fail-linux-distributions
https://github.com/theori-io/copy-fail-CVE-2026-31431
https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC

Fixed in


          1.12.7

References

Updated Jun 09, 2026 · Source: OSV.dev

Dec 12, 2024

v1.9.0-alpha.0 pre

1 CVE

GHSA-m38g-vww2-mvgx May 07, 2026

Talos Linux has a local privilege escalation from untrusted workloads

7.5 / 10

High

Local High Low None Changed High High None

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:

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.
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).
At this point, an attacker achieved code execution inside a privileged pod, which allows to escape to the host.
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.

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

https://copy.fail/
https://xint.io/blog/copy-fail-linux-distributions
https://github.com/theori-io/copy-fail-CVE-2026-31431
https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC

Fixed in


          1.12.7

References

Updated Jun 09, 2026 · Source: OSV.dev

Oct 18, 2024

v1.8.1 minor

1 CVE

GHSA-m38g-vww2-mvgx May 07, 2026

Talos Linux has a local privilege escalation from untrusted workloads

7.5 / 10

High

Local High Low None Changed High High None

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:

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.
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).
At this point, an attacker achieved code execution inside a privileged pod, which allows to escape to the host.
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.

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

https://copy.fail/
https://xint.io/blog/copy-fail-linux-distributions
https://github.com/theori-io/copy-fail-CVE-2026-31431
https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC

Fixed in


          1.12.7

References

Updated Jun 09, 2026 · Source: OSV.dev

Oct 08, 2024

v1.8.0-beta.0 pre

1 CVE

GHSA-m38g-vww2-mvgx May 07, 2026

Talos Linux has a local privilege escalation from untrusted workloads

7.5 / 10

High

Local High Low None Changed High High None

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:

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.
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).
At this point, an attacker achieved code execution inside a privileged pod, which allows to escape to the host.
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.

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

https://copy.fail/
https://xint.io/blog/copy-fail-linux-distributions
https://github.com/theori-io/copy-fail-CVE-2026-31431
https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC

Fixed in


          1.12.7

References

Updated Jun 09, 2026 · Source: OSV.dev

Sep 09, 2024

v1.7.6 patch

1 CVE

GHSA-m38g-vww2-mvgx May 07, 2026

Talos Linux has a local privilege escalation from untrusted workloads

7.5 / 10

High

Local High Low None Changed High High None

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:

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.
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).
At this point, an attacker achieved code execution inside a privileged pod, which allows to escape to the host.
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.

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

https://copy.fail/
https://xint.io/blog/copy-fail-linux-distributions
https://github.com/theori-io/copy-fail-CVE-2026-31431
https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC

Fixed in


          1.12.7

References

Updated Jun 09, 2026 · Source: OSV.dev

Aug 06, 2024

v1.7.4 minor

1 CVE

GHSA-m38g-vww2-mvgx May 07, 2026

Talos Linux has a local privilege escalation from untrusted workloads

7.5 / 10

High

Local High Low None Changed High High None

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:

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.
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).
At this point, an attacker achieved code execution inside a privileged pod, which allows to escape to the host.
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.

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

https://copy.fail/
https://xint.io/blog/copy-fail-linux-distributions
https://github.com/theori-io/copy-fail-CVE-2026-31431
https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC

Fixed in


          1.12.7

References

Updated Jun 09, 2026 · Source: OSV.dev

May 30, 2024

v1.6.7 patch

1 CVE

GHSA-m38g-vww2-mvgx May 07, 2026

Talos Linux has a local privilege escalation from untrusted workloads

7.5 / 10

High

Local High Low None Changed High High None

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:

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.
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).
At this point, an attacker achieved code execution inside a privileged pod, which allows to escape to the host.
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.

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

https://copy.fail/
https://xint.io/blog/copy-fail-linux-distributions
https://github.com/theori-io/copy-fail-CVE-2026-31431
https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC

Fixed in


          1.12.7

References

Updated Jun 09, 2026 · Source: OSV.dev

Mar 20, 2024

v1.7.0-alpha.1 pre

1 CVE

GHSA-m38g-vww2-mvgx May 07, 2026

Talos Linux has a local privilege escalation from untrusted workloads

7.5 / 10

High

Local High Low None Changed High High None

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:

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.
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).
At this point, an attacker achieved code execution inside a privileged pod, which allows to escape to the host.
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.

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

https://copy.fail/
https://xint.io/blog/copy-fail-linux-distributions
https://github.com/theori-io/copy-fail-CVE-2026-31431
https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC

Fixed in


          1.12.7

References

Updated Jun 09, 2026 · Source: OSV.dev

Mar 14, 2024

v1.6.2 minor

2 CVEs

GHSA-m38g-vww2-mvgx May 07, 2026

Talos Linux has a local privilege escalation from untrusted workloads

7.5 / 10

High

Local High Low None Changed High High None

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:

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.
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).
At this point, an attacker achieved code execution inside a privileged pod, which allows to escape to the host.
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.

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

https://copy.fail/
https://xint.io/blog/copy-fail-linux-distributions
https://github.com/theori-io/copy-fail-CVE-2026-31431
https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC

Fixed in


          1.12.7

References

Updated Jun 09, 2026 · Source: OSV.dev

GHSA-g5p6-327m-3fxx Feb 02, 2024

Talos Linux ships runc vulnerable to the escape to the host attack

8.6 / 10

High

Local Low None Required Changed High High High

Impact

Snyk has discovered a vulnerability in all versions of runc <=1.1.11, as used by the Docker engine, along with other containerization technologies such as Kubernetes. Exploitation of this issue can result in container escape to the underlying host OS, either through executing a malicious image or building an image using a malicious Dockerfile or upstream image (i.e., when using FROM). This issue has been assigned the CVE-2024-21626.

Patches

runc runtime was updated to 1.1.12 in Talos v1.5.6 and v1.6.4.

Workarounds

Inspect the workloads running on the cluster to make sure they are not trying to exploit the vulnerability.

References

Fixed in


          1.5.6


          1.6.4

References

Updated Feb 02, 2024 · Source: OSV.dev

Jan 18, 2024

v1.6.0-alpha.1 pre

1 CVE

GHSA-m38g-vww2-mvgx May 07, 2026

Talos Linux has a local privilege escalation from untrusted workloads

7.5 / 10

High

Local High Low None Changed High High None

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:

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.
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).
At this point, an attacker achieved code execution inside a privileged pod, which allows to escape to the host.
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.

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

https://copy.fail/
https://xint.io/blog/copy-fail-linux-distributions
https://github.com/theori-io/copy-fail-CVE-2026-31431
https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC

Fixed in


          1.12.7

References

Updated Jun 09, 2026 · Source: OSV.dev

Oct 17, 2023

v1.4.8 patch

2 CVEs

GHSA-m38g-vww2-mvgx May 07, 2026

Talos Linux has a local privilege escalation from untrusted workloads

7.5 / 10

High

Local High Low None Changed High High None

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:

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.
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).
At this point, an attacker achieved code execution inside a privileged pod, which allows to escape to the host.
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.

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

https://copy.fail/
https://xint.io/blog/copy-fail-linux-distributions
https://github.com/theori-io/copy-fail-CVE-2026-31431
https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC

Fixed in


          1.12.7

References

Updated Jun 09, 2026 · Source: OSV.dev

GHSA-g5p6-327m-3fxx Feb 02, 2024

Talos Linux ships runc vulnerable to the escape to the host attack

8.6 / 10

High

Local Low None Required Changed High High High

Impact

Snyk has discovered a vulnerability in all versions of runc <=1.1.11, as used by the Docker engine, along with other containerization technologies such as Kubernetes. Exploitation of this issue can result in container escape to the underlying host OS, either through executing a malicious image or building an image using a malicious Dockerfile or upstream image (i.e., when using FROM). This issue has been assigned the CVE-2024-21626.

Patches

runc runtime was updated to 1.1.12 in Talos v1.5.6 and v1.6.4.

Workarounds

Inspect the workloads running on the cluster to make sure they are not trying to exploit the vulnerability.

References

Fixed in


          1.5.6


          1.6.4

References

Updated Feb 02, 2024 · Source: OSV.dev

Aug 10, 2023

v1.4.7 minor

2 CVEs

GHSA-m38g-vww2-mvgx May 07, 2026

Talos Linux has a local privilege escalation from untrusted workloads

7.5 / 10

High

Local High Low None Changed High High None

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:

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.
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).
At this point, an attacker achieved code execution inside a privileged pod, which allows to escape to the host.
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.

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

https://copy.fail/
https://xint.io/blog/copy-fail-linux-distributions
https://github.com/theori-io/copy-fail-CVE-2026-31431
https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC

Fixed in


          1.12.7

References

Updated Jun 09, 2026 · Source: OSV.dev

GHSA-g5p6-327m-3fxx Feb 02, 2024

Talos Linux ships runc vulnerable to the escape to the host attack

8.6 / 10

High

Local Low None Required Changed High High High

Impact

Snyk has discovered a vulnerability in all versions of runc <=1.1.11, as used by the Docker engine, along with other containerization technologies such as Kubernetes. Exploitation of this issue can result in container escape to the underlying host OS, either through executing a malicious image or building an image using a malicious Dockerfile or upstream image (i.e., when using FROM). This issue has been assigned the CVE-2024-21626.

Patches

runc runtime was updated to 1.1.12 in Talos v1.5.6 and v1.6.4.

Workarounds

Inspect the workloads running on the cluster to make sure they are not trying to exploit the vulnerability.

References

Fixed in


          1.5.6


          1.6.4

References

Updated Feb 02, 2024 · Source: OSV.dev

Jul 26, 2023

v1.3.7 minor

2 CVEs

GHSA-m38g-vww2-mvgx May 07, 2026

Talos Linux has a local privilege escalation from untrusted workloads

7.5 / 10

High

Local High Low None Changed High High None

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:

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.
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).
At this point, an attacker achieved code execution inside a privileged pod, which allows to escape to the host.
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.

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

https://copy.fail/
https://xint.io/blog/copy-fail-linux-distributions
https://github.com/theori-io/copy-fail-CVE-2026-31431
https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC

Fixed in


          1.12.7

References

Updated Jun 09, 2026 · Source: OSV.dev

GHSA-g5p6-327m-3fxx Feb 02, 2024

Talos Linux ships runc vulnerable to the escape to the host attack

8.6 / 10

High

Local Low None Required Changed High High High

Impact

Snyk has discovered a vulnerability in all versions of runc <=1.1.11, as used by the Docker engine, along with other containerization technologies such as Kubernetes. Exploitation of this issue can result in container escape to the underlying host OS, either through executing a malicious image or building an image using a malicious Dockerfile or upstream image (i.e., when using FROM). This issue has been assigned the CVE-2024-21626.

Patches

runc runtime was updated to 1.1.12 in Talos v1.5.6 and v1.6.4.

Workarounds

Inspect the workloads running on the cluster to make sure they are not trying to exploit the vulnerability.

References

Fixed in


          1.5.6


          1.6.4

References

Updated Feb 02, 2024 · Source: OSV.dev

Apr 06, 2023

v1.3.0-beta.2 pre

2 CVEs

GHSA-m38g-vww2-mvgx May 07, 2026

Talos Linux has a local privilege escalation from untrusted workloads

7.5 / 10

High

Local High Low None Changed High High None

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:

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.
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).
At this point, an attacker achieved code execution inside a privileged pod, which allows to escape to the host.
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.

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

https://copy.fail/
https://xint.io/blog/copy-fail-linux-distributions
https://github.com/theori-io/copy-fail-CVE-2026-31431
https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC

Fixed in


          1.12.7

References

Updated Jun 09, 2026 · Source: OSV.dev

GHSA-g5p6-327m-3fxx Feb 02, 2024

Talos Linux ships runc vulnerable to the escape to the host attack

8.6 / 10

High

Local Low None Required Changed High High High

Impact

Snyk has discovered a vulnerability in all versions of runc <=1.1.11, as used by the Docker engine, along with other containerization technologies such as Kubernetes. Exploitation of this issue can result in container escape to the underlying host OS, either through executing a malicious image or building an image using a malicious Dockerfile or upstream image (i.e., when using FROM). This issue has been assigned the CVE-2024-21626.

Patches

runc runtime was updated to 1.1.12 in Talos v1.5.6 and v1.6.4.

Workarounds

Inspect the workloads running on the cluster to make sure they are not trying to exploit the vulnerability.

References

Fixed in


          1.5.6


          1.6.4

References

Updated Feb 02, 2024 · Source: OSV.dev

Dec 09, 2022

v1.2.0-alpha.0 pre

3 CVEs

GHSA-m38g-vww2-mvgx May 07, 2026

Talos Linux has a local privilege escalation from untrusted workloads

7.5 / 10

High

Local High Low None Changed High High None

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:

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.
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).
At this point, an attacker achieved code execution inside a privileged pod, which allows to escape to the host.
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.

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

https://copy.fail/
https://xint.io/blog/copy-fail-linux-distributions
https://github.com/theori-io/copy-fail-CVE-2026-31431
https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC

Fixed in


          1.12.7

References

Updated Jun 09, 2026 · Source: OSV.dev

GHSA-g5p6-327m-3fxx Feb 02, 2024

Talos Linux ships runc vulnerable to the escape to the host attack

8.6 / 10

High

Local Low None Required Changed High High High

Impact

Snyk has discovered a vulnerability in all versions of runc <=1.1.11, as used by the Docker engine, along with other containerization technologies such as Kubernetes. Exploitation of this issue can result in container escape to the underlying host OS, either through executing a malicious image or building an image using a malicious Dockerfile or upstream image (i.e., when using FROM). This issue has been assigned the CVE-2024-21626.

Patches

runc runtime was updated to 1.1.12 in Talos v1.5.6 and v1.6.4.

Workarounds

Inspect the workloads running on the cluster to make sure they are not trying to exploit the vulnerability.

References

Fixed in


          1.5.6


          1.6.4

References

Updated Feb 02, 2024 · Source: OSV.dev

GHSA-jr8j-2jhp-m67v Sep 16, 2022

nftables binding to an already bound chain

Medium

Impact

An issue was discovered in net/netfilter/nf_tables_api.c in the Linux kernel. A denial of service can occur upon binding to an already bound chain.

Affected by this vulnerability is the function nft_verdict_init of the file net/netfilter/nf_tables_api.c. The manipulation with an unknown input leads to a denial of service vulnerability. The program does not release or incorrectly releases a resource before it is made available for re-use.

Patches

The fix has been backported to 5.15.64 version of the upstream Linux kernel (5.15 is the upstream Kernel long term version Talos ships with). Talos >= v1.2.0 is shipped with Linux Kernel 5.15.64 fixing the above issue.

Workarounds

It's recommended to upgrade

References

https://www.sesin.at/2022/09/02/cve-2022-39190-linux-kernel-up-to-5-19-5-nf_tables_api-c-nft_verdict_init-denial-of-service/
https://nvd.nist.gov/vuln/detail/CVE-2022-39190

For more information

Email us at security@siderolabs.com

Fixed in


          1.2.0

References

Updated Sep 16, 2022 · Source: OSV.dev

Jun 30, 2022

v1.1.0 minor

3 CVEs

GHSA-m38g-vww2-mvgx May 07, 2026

Talos Linux has a local privilege escalation from untrusted workloads

7.5 / 10

High

Local High Low None Changed High High None

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:

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.
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).
At this point, an attacker achieved code execution inside a privileged pod, which allows to escape to the host.
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.

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

https://copy.fail/
https://xint.io/blog/copy-fail-linux-distributions
https://github.com/theori-io/copy-fail-CVE-2026-31431
https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC

Fixed in


          1.12.7

References

Updated Jun 09, 2026 · Source: OSV.dev

GHSA-g5p6-327m-3fxx Feb 02, 2024

Talos Linux ships runc vulnerable to the escape to the host attack

8.6 / 10

High

Local Low None Required Changed High High High

Impact

Snyk has discovered a vulnerability in all versions of runc <=1.1.11, as used by the Docker engine, along with other containerization technologies such as Kubernetes. Exploitation of this issue can result in container escape to the underlying host OS, either through executing a malicious image or building an image using a malicious Dockerfile or upstream image (i.e., when using FROM). This issue has been assigned the CVE-2024-21626.

Patches

runc runtime was updated to 1.1.12 in Talos v1.5.6 and v1.6.4.

Workarounds

Inspect the workloads running on the cluster to make sure they are not trying to exploit the vulnerability.

References

Fixed in


          1.5.6


          1.6.4

References

Updated Feb 02, 2024 · Source: OSV.dev

GHSA-jr8j-2jhp-m67v Sep 16, 2022

nftables binding to an already bound chain

Medium

Impact

An issue was discovered in net/netfilter/nf_tables_api.c in the Linux kernel. A denial of service can occur upon binding to an already bound chain.

Affected by this vulnerability is the function nft_verdict_init of the file net/netfilter/nf_tables_api.c. The manipulation with an unknown input leads to a denial of service vulnerability. The program does not release or incorrectly releases a resource before it is made available for re-use.

Patches

The fix has been backported to 5.15.64 version of the upstream Linux kernel (5.15 is the upstream Kernel long term version Talos ships with). Talos >= v1.2.0 is shipped with Linux Kernel 5.15.64 fixing the above issue.

Workarounds

It's recommended to upgrade

References

https://www.sesin.at/2022/09/02/cve-2022-39190-linux-kernel-up-to-5-19-5-nf_tables_api-c-nft_verdict_init-denial-of-service/
https://nvd.nist.gov/vuln/detail/CVE-2022-39190

For more information

Email us at security@siderolabs.com

Fixed in


          1.2.0

References

Updated Sep 16, 2022 · Source: OSV.dev

Jun 21, 2022

v1.0.1 major

3 CVEs

GHSA-m38g-vww2-mvgx May 07, 2026

Talos Linux has a local privilege escalation from untrusted workloads

7.5 / 10

High

Local High Low None Changed High High None

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:

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.
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).
At this point, an attacker achieved code execution inside a privileged pod, which allows to escape to the host.
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.

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

https://copy.fail/
https://xint.io/blog/copy-fail-linux-distributions
https://github.com/theori-io/copy-fail-CVE-2026-31431
https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC

Fixed in


          1.12.7

References

Updated Jun 09, 2026 · Source: OSV.dev

GHSA-g5p6-327m-3fxx Feb 02, 2024

Talos Linux ships runc vulnerable to the escape to the host attack

8.6 / 10

High

Local Low None Required Changed High High High

Impact

Snyk has discovered a vulnerability in all versions of runc <=1.1.11, as used by the Docker engine, along with other containerization technologies such as Kubernetes. Exploitation of this issue can result in container escape to the underlying host OS, either through executing a malicious image or building an image using a malicious Dockerfile or upstream image (i.e., when using FROM). This issue has been assigned the CVE-2024-21626.

Patches

runc runtime was updated to 1.1.12 in Talos v1.5.6 and v1.6.4.

Workarounds

Inspect the workloads running on the cluster to make sure they are not trying to exploit the vulnerability.

References

Fixed in


          1.5.6


          1.6.4

References

Updated Feb 02, 2024 · Source: OSV.dev

GHSA-jr8j-2jhp-m67v Sep 16, 2022

nftables binding to an already bound chain

Medium

Impact

An issue was discovered in net/netfilter/nf_tables_api.c in the Linux kernel. A denial of service can occur upon binding to an already bound chain.

Affected by this vulnerability is the function nft_verdict_init of the file net/netfilter/nf_tables_api.c. The manipulation with an unknown input leads to a denial of service vulnerability. The program does not release or incorrectly releases a resource before it is made available for re-use.

Patches

The fix has been backported to 5.15.64 version of the upstream Linux kernel (5.15 is the upstream Kernel long term version Talos ships with). Talos >= v1.2.0 is shipped with Linux Kernel 5.15.64 fixing the above issue.

Workarounds

It's recommended to upgrade

References

https://www.sesin.at/2022/09/02/cve-2022-39190-linux-kernel-up-to-5-19-5-nf_tables_api-c-nft_verdict_init-denial-of-service/
https://nvd.nist.gov/vuln/detail/CVE-2022-39190

For more information

Email us at security@siderolabs.com

Fixed in


          1.2.0

References

Updated Sep 16, 2022 · Source: OSV.dev

Apr 04, 2022

v0.14.3 minor

3 CVEs

GHSA-m38g-vww2-mvgx May 07, 2026

Talos Linux has a local privilege escalation from untrusted workloads

7.5 / 10

High

Local High Low None Changed High High None

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:

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.
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).
At this point, an attacker achieved code execution inside a privileged pod, which allows to escape to the host.
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.

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

https://copy.fail/
https://xint.io/blog/copy-fail-linux-distributions
https://github.com/theori-io/copy-fail-CVE-2026-31431
https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC

Fixed in


          1.12.7

References

Updated Jun 09, 2026 · Source: OSV.dev

GHSA-g5p6-327m-3fxx Feb 02, 2024

Talos Linux ships runc vulnerable to the escape to the host attack

8.6 / 10

High

Local Low None Required Changed High High High

Impact

Snyk has discovered a vulnerability in all versions of runc <=1.1.11, as used by the Docker engine, along with other containerization technologies such as Kubernetes. Exploitation of this issue can result in container escape to the underlying host OS, either through executing a malicious image or building an image using a malicious Dockerfile or upstream image (i.e., when using FROM). This issue has been assigned the CVE-2024-21626.

Patches

runc runtime was updated to 1.1.12 in Talos v1.5.6 and v1.6.4.

Workarounds

Inspect the workloads running on the cluster to make sure they are not trying to exploit the vulnerability.

References

Fixed in


          1.5.6


          1.6.4

References

Updated Feb 02, 2024 · Source: OSV.dev

GHSA-jr8j-2jhp-m67v Sep 16, 2022

nftables binding to an already bound chain

Medium

Impact

An issue was discovered in net/netfilter/nf_tables_api.c in the Linux kernel. A denial of service can occur upon binding to an already bound chain.

Affected by this vulnerability is the function nft_verdict_init of the file net/netfilter/nf_tables_api.c. The manipulation with an unknown input leads to a denial of service vulnerability. The program does not release or incorrectly releases a resource before it is made available for re-use.

Patches

The fix has been backported to 5.15.64 version of the upstream Linux kernel (5.15 is the upstream Kernel long term version Talos ships with). Talos >= v1.2.0 is shipped with Linux Kernel 5.15.64 fixing the above issue.

Workarounds

It's recommended to upgrade

References

https://www.sesin.at/2022/09/02/cve-2022-39190-linux-kernel-up-to-5-19-5-nf_tables_api-c-nft_verdict_init-denial-of-service/
https://nvd.nist.gov/vuln/detail/CVE-2022-39190

For more information

Email us at security@siderolabs.com

Fixed in


          1.2.0

References

Updated Sep 16, 2022 · Source: OSV.dev

Mar 03, 2022

v0.15.0-alpha.0 pre

3 CVEs

GHSA-m38g-vww2-mvgx May 07, 2026

Talos Linux has a local privilege escalation from untrusted workloads

7.5 / 10

High

Local High Low None Changed High High None

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:

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.
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).
At this point, an attacker achieved code execution inside a privileged pod, which allows to escape to the host.
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.

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

https://copy.fail/
https://xint.io/blog/copy-fail-linux-distributions
https://github.com/theori-io/copy-fail-CVE-2026-31431
https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC

Fixed in


          1.12.7

References

Updated Jun 09, 2026 · Source: OSV.dev

GHSA-g5p6-327m-3fxx Feb 02, 2024

Talos Linux ships runc vulnerable to the escape to the host attack

8.6 / 10

High

Local Low None Required Changed High High High

Impact

Snyk has discovered a vulnerability in all versions of runc <=1.1.11, as used by the Docker engine, along with other containerization technologies such as Kubernetes. Exploitation of this issue can result in container escape to the underlying host OS, either through executing a malicious image or building an image using a malicious Dockerfile or upstream image (i.e., when using FROM). This issue has been assigned the CVE-2024-21626.

Patches

runc runtime was updated to 1.1.12 in Talos v1.5.6 and v1.6.4.

Workarounds

Inspect the workloads running on the cluster to make sure they are not trying to exploit the vulnerability.

References

Fixed in


          1.5.6


          1.6.4

References

Updated Feb 02, 2024 · Source: OSV.dev

GHSA-jr8j-2jhp-m67v Sep 16, 2022

nftables binding to an already bound chain

Medium

Impact

An issue was discovered in net/netfilter/nf_tables_api.c in the Linux kernel. A denial of service can occur upon binding to an already bound chain.

Affected by this vulnerability is the function nft_verdict_init of the file net/netfilter/nf_tables_api.c. The manipulation with an unknown input leads to a denial of service vulnerability. The program does not release or incorrectly releases a resource before it is made available for re-use.

Patches

The fix has been backported to 5.15.64 version of the upstream Linux kernel (5.15 is the upstream Kernel long term version Talos ships with). Talos >= v1.2.0 is shipped with Linux Kernel 5.15.64 fixing the above issue.

Workarounds

It's recommended to upgrade

References

https://www.sesin.at/2022/09/02/cve-2022-39190-linux-kernel-up-to-5-19-5-nf_tables_api-c-nft_verdict_init-denial-of-service/
https://nvd.nist.gov/vuln/detail/CVE-2022-39190

For more information

Email us at security@siderolabs.com

Fixed in


          1.2.0

References

Updated Sep 16, 2022 · Source: OSV.dev

Dec 30, 2021

Activity

Reach

Details