Talos Linux: Support bundle does not redact registry credentials

CISA KEV is observed exploitation evidence. FIRST EPSS is a dated prediction of exploitation in the next 30 days. Missing scores are unknown. This collector requests predictions only for explicit CVE aliases in the public NuGet archive; Microsoft release views retain their existing prediction scope.

No collected risk observation for these identifiers. This does not establish absence of exploitation or a zero probability.

Talos Linux is a Linux distribution built for Kubernetes deployments. Prior to 1.12.9 and 1.13.3, talosctl support includes the auth field from resources/registryconfigs.cri.talos.dev.yaml and sensitive content from etcfilespecs.files.talos.dev.yaml in generated support bundles instead of marking or redacting those resources. An operator who shares a bundle with an unintended party can therefore disclose private registry authentication parameters, with impact depending on the registry's network exposure and credential privileges. Talos 1.14 and later encrypt support bundles by default, which reduces but does not replace the need for redaction. This issue is fixed in versions 1.12.9 and 1.13.3.

Source published

14 Oct 2026 16:09:11 UTC

Source modified

14 Oct 2026 16:09:11 UTC

Observed here

23 Oct 2026 15:48:27 UTC

Source terms

CVE Program Terms of Use

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: cve-program · CVE Program Terms of Use. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · 3.3 CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N

Talos Linux is a Linux distribution built for Kubernetes deployments. Prior to 1.12.9 and 1.13.3, talosctl support includes the auth field from resources/registryconfigs.cri.talos.dev.yaml and sensitive content from etcfilespecs.files.talos.dev.yaml in generated support bundles instead of marking or redacting those resources. An operator who shares a bundle with an unintended party can therefore disclose private registry authentication parameters, with impact depending on the registry's network exposure and credential privileges. Talos 1.14 and later encrypt support bundles by default, which reduces but does not replace the need for redaction. This issue is fixed in versions 1.12.9 and 1.13.3.

Source published

14 Oct 2026 17:19:11 UTC

Source modified

16 Oct 2026 16:00:33 UTC

Observed here

25 Oct 2026 16:19:04 UTC

Source terms

NIST NVD usage terms; underlying source attribution retained

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: nvd · NIST NVD usage terms; underlying source attribution retained. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS 3.1 · [email protected] · Secondary · 3.3 CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N

### Summary 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, from denial of service, to data loss and possibly existing tag hijacking leading to supply chain compromise, for the affected parties which were under the impression that the support bundle is redacted of sensitive information and thus can be shared publicly. ### Notes Talos 1.14+ by default encrypts the support bundle to the age recipients specified (defaulting to siderolabs GitHub org members), so the impact is even lower. ### Environment - Talos version: v1.13.0 - Kubernetes version: 1.35.3 - Platform: amd64

Source published

15 Oct 2026 20:20:16 UTC

Source modified

26 Oct 2026 14:45:05 UTC

Observed here

26 Oct 2026 15:37:07 UTC

Source terms

GitHub Advisory Database · CC-BY-4.0

Original source record · Cite this exact observation · Complete original publisher JSON

This view projects the publisher's source fields for reading; the original JSON retains additional fields and CVE enrichment containers. Attribution: osv · GitHub Advisory Database · CC-BY-4.0. Source text is retained; field grouping and change labels are provided by ChangeIntel.

CVSS_V3 · CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N

Publisher rating · LOW