Open actionable advisories and recorded vendor fixes. This public package view has no inventory attached and cannot establish whether your deployment is affected. A vendor fix never resolves your finding; verify your installed version and the source guidance.
Open advisories
4 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/siderolabs/talos < 1.14.0-alpha.0.0.20260513110206-76080416beee
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee· Vendor fix available
Issue
When generating a support bundle with `talosctl support` the credentials entered for private registries are included in the bundle. Details Within the generated support bundle, inside `resources/registryconfigs.cri.talos.dev.yaml` the `auth` field of the spec is retained. The same, potentially sensitive information is present within `etcfilespecs.files.talos.dev.yaml`. PoC Simply run `talosctl -n [...] support` on a cluster with a `RegistryAuthConfig` resource Impact The problem itself is minor, however, anyone who has ever uploaded a support.zip bundle on a github issue, slack thread or public forum could have potentially leaked their internal authentication parameters for a private registry. In most situations, if the network and credentials are set correctly, this should not be a problem. On the other hand, if the affected registry is publicly accessible, and the provided credentials have write access to it, this could lead to possibly serious consequences,…
Recommended action: Upgrade to 1.14.0-alpha.0.0.20260513110206-76080416beee (pre-release) or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
A vulnerability in the Linux kernel's algifaead subsystem (CVE-2026-31431, "copy.fail") allows an unprivileged container workload to corrupt arbitrary file page-cache pages via the AFALG 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…
Recommended action: Upgrade to 1.12.7 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Go github.com/siderolabs/talos >= 1.6.0, < 1.6.4; < 1.5.6
Fixed in
1.6.41.5.6· Vendor fix available
Issue
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 CVE-2024-21626 Vulnerability: runc process.cwd and leaked fds container breakout
Recommended action: Upgrade to 1.6.4 or 1.5.6 by release line, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact An issue was discovered in net/netfilter/nftablesapi.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 nftverdictinit of the file net/netfilter/nftablesapi.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-nftablesapi-c-nftverdictinit-denial-of-service/ - https://nvd.nist.gov/vuln/detail/CVE-2022-39190 For more information - Email us at security@siderolabs.com
Recommended action: Upgrade to 1.2.0 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.