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
3 actionable advisories, newest first. Withdrawn advisories and news are excluded. Coverage is partial.
Go github.com/talos-systems/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.
Impact Talos worker nodes use a join token to get accepted into the Talos cluster. A misconfigured Kubernetes environment may allow workloads to access the join token of the worker node. A malicious workload could then use the join token to construct a Talos CSR (certificate signing request). Due to improper validation while signing a worker node CSR, a Talos control plane node might issue a Talos certificate which allows full access to the Talos API to a worker node that presented a maliciously constructed CSR. Accessing the Talos API with full access on a control plane node might reveal sensitive information, which could allow full-level access to the cluster (Kubernetes and Talos PKI, etc.) In order to exploit the weakness, a Kubernetes workload would need to access the join token, and then construct a specific kind of Talos CSR in order to obtain a privileged certificate. The Talos API join token is stored in the machine configuration on the worker node. When configured…
Recommended action: Upgrade to 1.2.2 or later, then redeploy and verify.A vendor fix does not resolve your finding until you verify it in your own systems.
Impact A race condition was found in the Linux kernel's IP framework for transforming packets (XFRM subsystem) when multiple calls to xfrmprobealgs occurred simultaneously. This flaw could allow a local attacker to potentially trigger an out-of-bounds write or leak kernel heap memory by performing an out-of-bounds read and copying it into a socket. 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. Kubernetes workloads running in Talos are not affected since user namespaces are disabled in Talos kernel config. So an unprivileged user cannot obtain CAPNETADMIN by unsharing. However untrusted workloads that run with privileged: true or having NETADMIN capability poses a risk. Workarounds Audit kubernetes workloads running in the cluster with privileged: true set or having NETADMIN capability and assess the threat…
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.