Vulnerabilities in pkg:golang/github.com/siderolabs/talos

PACKAGE
Advisory Summary

GHSA-m38g-vww2-mvgx is a HIGH (CVSS 7.5) talos linux has a local vulnerability (CWE-669: Incorrect Resource Transfer Between Spheres) affecting Github.com/siderolabs/talos libraries in the Go ecosystem. The issue involves talos linux has a local privilege escalation from untrusted workloads. Remediation is available by upgrading affected packages to version 1.12.7.

3 Known Advisory Record(s)
Package Vulnerability Intelligence

pkg:golang/github.com/siderolabs/talos

3 Known Advisory Record(s)

Vulnerability advisories affecting package pkg:golang/github.com/siderolabs/talos. Select an advisory below to view technical details or fixes.

Advisory ID CVE / NVD Severity Summary
GHSA-m38g-vww2-mvgx - HIGH Talos Linux has a local privilege escalation from untrusted workloads
GHSA-g5p6-327m-3fxx - HIGH Talos Linux ships runc vulnerable to the escape to the host attack
GHSA-jr8j-2jhp-m67v - MODERATE nftables binding to an already bound chain

GHSA-m38g-vww2-mvgx at a Glance

CVE Identifier N/A
GHSA Identifier GHSA-m38g-vww2-mvgx
Severity HIGH
CVSS v3.1 Base Score 7.5
CWE Classification CWE-669: Incorrect Resource Transfer Between Spheres
Affected Product Github.com/siderolabs/talos
Package Ecosystem Go
Published Date
Last Updated

Security Impact

CVSS: 7.5

The security impact metrics below are parsed directly from the CVSS v3.1 vector string (CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N).

Attack Vector Local (AV:L)
Attack Complexity High (AC:H)
Privileges Required Low (PR:L)
User Interaction None (UI:N)
Scope Changed (S:C)
Confidentiality High (C:H)
Integrity High (I:H)
Availability None (A:N)

How to Fix GHSA-m38g-vww2-mvgx

To remediate this vulnerability, upgrade all affected Github.com/siderolabs/talos dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

github.com/siderolabs/talos fixed: 1.12.7
Upgrade github.com/siderolabs/talos to 1.12.7
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

inspect dependencies for github.com/siderolabs/talos

How to Check if You Are Affected

To determine whether your application is affected by GHSA-m38g-vww2-mvgx, inspect your project dependencies for Github.com/siderolabs/talos:

inspect dependencies for github.com/siderolabs/talos

Analyze the terminal output to locate any version of Github.com/siderolabs/talos in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 1.12.7), your application is affected.

Note: Verify declared build manifests and deployed runtime container environments.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-669: Incorrect Resource Transfer Between Spheres, where the product does not properly transfer a resource/behavior to another sphere, or improperly imports a resource/behavior from another sphere, in a manner that provides unintended control over that resource. In Github.com/siderolabs/talos, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

### Summary A vulnerability in the Linux kernel's algif_aead subsystem (CVE-2026-31431, "copy.fail") allows an unprivileged container workload to corrupt arbitrary file page-cache pages via the AF_ALG crypto interface and splice(). On Talos Linux, this vulnerability can be chained into a complete node compromise: an attacker who can schedule a pod on a worker node can, without any elevated Kubernetes permissions, achieve arbitrary code execution as root on the host (by poisoning a binary inside a privileged pod, or poisoning a binary which runs with elevated privileges like a CNI binary), access host filesystem, including node secrets. The exploit does not require kernel debugging, race conditions, or any prior privileges beyond the ability to create a pod. ### Impact An attacker with the ability to deploy a Kubernetes pod on an affected node can: 1. Corrupt the page-cache of /usr/sbin/nft in the containerd snapshot layer shared between the attacker's pod and the kube-proxy DaemonSet. Because containerd reuses XFS page-cache pages across overlayfs mounts sharing the same lower layer, the corruption is immediately visible to all containers using that image layer — including privileged system DaemonSets. 2. Execute arbitrary code inside kube-proxy — a privileged DaemonSet running on every node with all Linux capabilities (privileged: true) and host network access — the next time kube-proxy invokes nft as part of its nftables reconciliation loop (typically within seconds). 3. At this point, an attacker achieved code execution inside a privileged pod, which allows to escape to the host. 4. Same attack can be planted by infiltrating other binaries running as privileged, for example a CNI plugin. ### Patches Upgrade to Talos v1.13.0 or Talos v1.12.7 which ships Linux kernel 6.18.25. The kernel fix for CVE-2026-31431 (algif_aead in-place optimization revert) was committed upstream in Linux 6.18.22 and is included in all Talos releases from v1.13.0 and Talos 1.12.7 onwards. ### Workarounds There are multiple workarounds available based on the situation, but we really recommend to upgrade. #### Option 1 - Change kernel arguments Add a kernel argument with `initcall_blacklist=algif_aead_init` by upgrading Talos to the same version. > Note: this either requires setting `machine.kernel.extraKernelArgs` if using BIOS based boot or upgrading with a new image from factory/imager generated image by setting the extra kernel args. See [Boot Assets](https://docs.siderolabs.com/talos/v1.13/platform-specific-installations/boot-assets) #### Option 2 - Deploy all workload pods with a seccomp profile denying creating `AF_ALG` socket creation `patch.yaml` ```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: ```yaml ... 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](https://github.com/cozystack/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

GHSA-m38g-vww2-mvgx Affected Github.com/siderolabs/talos Versions

1 component(s)
Fixed Versions:
1.12.7
Product / Package Ecosystem Affected Versions Fixed Version
github.com/siderolabs/talos
Go
< 1.12.7
1.12.7

References

Frequently Asked Questions

What is GHSA-m38g-vww2-mvgx?
GHSA-m38g-vww2-mvgx is a security vulnerability in Github.com/siderolabs/talos involving Talos Linux has a local privilege escalation from untrusted workloads under CWE-669: Incorrect Resource Transfer Between Spheres.
Which Github.com/siderolabs/talos versions are affected?
Affected versions include releases prior to 1.12.7 across affected packages: github.com/siderolabs/talos.
What version fixes GHSA-m38g-vww2-mvgx?
Upgrading to 1.12.7 (or the latest patched release for your respective branch) resolves the vulnerability.
Is github.com/siderolabs/talos affected?
Yes, github.com/siderolabs/talos is affected in releases prior to 1.12.7. Upgrade your dependency to 1.12.7 or later.
What is the CVSS score of GHSA-m38g-vww2-mvgx?
GHSA-m38g-vww2-mvgx has a CVSS v3.1 base score of 7.5 (HIGH) with vector string CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N.
What CWE is associated with GHSA-m38g-vww2-mvgx?
GHSA-m38g-vww2-mvgx is classified under CWE-669: Incorrect Resource Transfer Between Spheres (The product does not properly transfer a resource/behavior to another sphere, or improperly imports a resource/behavior from another sphere, in a manner that provides unintended control over that resource.).
How can I check Go dependencies for GHSA-m38g-vww2-mvgx?
Run the dependency tree command: 'inspect dependencies for github.com/siderolabs/talos'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-m38g-vww2-mvgx",
  "modified" : "2026-06-08T23:43:27Z",
  "published" : "2026-05-07T02:38:02Z",
  "aliases" : [ ],
  "summary" : "Talos Linux has a local privilege escalation from untrusted workloads",
  "details" : "### Summary\n\nA 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. \n\nThe exploit does not require kernel debugging, race conditions, or any prior privileges beyond the ability to create a pod.\n\n### Impact\n\nAn attacker with the ability to deploy a Kubernetes pod on an affected node can:\n\n1. 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.\n2. 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).\n3. At this point, an attacker achieved code execution inside a privileged pod, which allows to escape to the host.\n4. Same attack can be planted by infiltrating other binaries running as privileged, for example a CNI plugin.\n\n### Patches\n\nUpgrade 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.\n\n### Workarounds\n\nThere are multiple workarounds available based on the situation, but we really recommend to upgrade.\n\n#### Option 1 - Change kernel arguments\n\nAdd a kernel argument with `initcall_blacklist=algif_aead_init` by upgrading Talos to the same version.\n\n> Note: this either requires setting `machine.kernel.extraKernelArgs` if using BIOS based boot or upgrading with a new image from factory/imager generated image by setting the extra kernel args. See [Boot Assets](https://docs.siderolabs.com/talos/v1.13/platform-specific-installations/boot-assets)\n\n#### Option 2 - Deploy all workload pods with a seccomp profile denying  creating `AF_ALG` socket creation\n\n`patch.yaml`\n\n```yaml\nmachine:\n  seccompProfiles:\n    - name: copy-fail-block.json\n      value:\n        defaultAction: SCMP_ACT_ALLOW\n        syscalls:\n          - names:\n              - socket\n            action: SCMP_ACT_ERRNO\n            args:\n              - index: 0\n                value: 38\n                op: SCMP_CMP_EQ\n```\n\nApply this patch to all machines in the cluster and set this for all the pod spec:\n\n```yaml\n...\nspec:\n      securityContext:\n        seccompProfile:\n          type: Localhost\n          localhostProfile: profiles/copy-fail-block.json\n```\n\n#### Option 3 - Block the syscall in runtime with a eBPF program\n\nSee [copy-fail-blocker](https://github.com/cozystack/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. \n\n### References\n\n* https://copy.fail/\n* https://xint.io/blog/copy-fail-linux-distributions\n* https://github.com/theori-io/copy-fail-CVE-2026-31431\n* https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC",
  "severity" : [ {
    "type" : "CVSS_V3",
    "score" : "CVSS:3.1/AV:L/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "Go",
      "name" : "github.com/siderolabs/talos"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0"
      }, {
        "fixed" : "1.12.7"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/siderolabs/talos/security/advisories/GHSA-m38g-vww2-mvgx"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-31431"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/Percivalll/Copy-Fail-CVE-2026-31431-Kubernetes-PoC"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/siderolabs/talos"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/theori-io/copy-fail-CVE-2026-31431"
  }, {
    "type" : "WEB",
    "url" : "https://xint.io/blog/copy-fail-linux-distributions"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-669" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-05-07T02:38:02Z",
    "nvd_published_at" : null
  }
}