# GHSA-m38g-vww2-mvgx: Talos Linux has a local privilege escalation from untrusted workloads

> An attacker with pod scheduling rights can escalate privileges to root on Talos Linux nodes by exploiting a kernel page-cache corruption vulnerability.

- **Severity:** Not scored
- **Exploited in the wild:** Not known
- **Login needed:** Any signed-in user
- **Attackable:** Local or same network only
- **Victim action needed:** Not needed
- **Fix available:** Yes
- **Published:** 7 May 2026

## What is GHSA-m38g-vww2-mvgx?

GHSA-m38g-vww2-mvgx is a vulnerability in github.com/siderolabs/talos, published on 7 May 2026. It can only be exploited from the same machine or local network, with no action from the victim.

### Official description

### Summary

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

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

### Impact

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

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

### Patches

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

### Workarounds

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

#### Option 1 - Change kernel arguments

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

> Note: this either requires setting `machine.kernel.extraKernelArgs` if using BIOS based boot or upgrading with a new image from factory/imager generated image by setting the extra kernel args. See [Boot Assets](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

## Which versions are affected by GHSA-m38g-vww2-mvgx?

2 open source packages ship an affected version, including github.com/siderolabs/talos.


| Package | Ecosystem | Affected | Fixed in |
| --- | --- | --- | --- |
| `github.com/siderolabs/talos` | Go | All versions | 1.12.7 |
| `github.com/siderolabs/talos` | Go | All versions | 1.12.7 |

## How do I fix GHSA-m38g-vww2-mvgx?

Upgrade github.com/siderolabs/talos to 1.12.7 or later.

## Is GHSA-m38g-vww2-mvgx being exploited?

There is no known exploitation of GHSA-m38g-vww2-mvgx in the wild and no public exploit code.

## Fix prompt for AI coding agents

```text
Check this codebase for GHSA-m38g-vww2-mvgx and fix it if it is affected.

What it is: GHSA-m38g-vww2-mvgx is a vulnerability in github.com/siderolabs/talos, published on 7 May 2026. It can only be exploited from the same machine or local network, with no action from the victim.
Exploitation: There is no known exploitation of GHSA-m38g-vww2-mvgx in the wild and no public exploit code.

Affected packages and fixed versions:
- github.com/siderolabs/talos (Go): affected all versions; fixed in 1.12.7
- github.com/siderolabs/talos (Go): affected all versions; fixed in 1.12.7

Task:
1. Search the dependency manifests and lockfiles (for example package.json, package-lock.json, requirements.txt, poetry.lock, uv.lock, pom.xml, build.gradle, go.mod, Cargo.lock, Gemfile.lock) and any Dockerfiles for the affected packages, including transitive dependencies.
2. If an affected version is in use, upgrade it to the fixed version for its release line with the project's package manager, so the lockfile is regenerated. Prefer the smallest upgrade that fixes it.
3. If there is no fix, or the upgrade would break the build, do not guess: explain the risk and the safest workaround instead.
4. Run the tests and summarise what changed and why.
5. If nothing in the project is affected, say so and change nothing.

Reference: https://insights.sbomify.com/GHSA-m38g-vww2-mvgx/ (Markdown: https://insights.sbomify.com/GHSA-m38g-vww2-mvgx/index.md)
```

## Sources

- OSV: https://osv.dev/vulnerability/GHSA-m38g-vww2-mvgx

---
From sbomify Insights: https://insights.sbomify.com/GHSA-m38g-vww2-mvgx/
Summaries are generated and may contain mistakes; the official description above is the record.