---
id: "CVE-2026-77564"
kind: "vulnerability"
aliases: ["CVE-2026-77564", "GHSA-7cxh-94cf-mfp6"]
title: "Talos Linux: Support bundle does not redact registry credentials"
severity: "low"
cvss: 3.3
epss: 0.00131
exploited: false
status: "open"
category: "infrastructure"
products: [{"name": "github.com/siderolabs/talos", "fixed": ["1.14.0-alpha.0.0.20260513110206-76080416beee"], "affected": "< 1.14.0-alpha.0.0.20260513110206-76080416beee", "ecosystem": "go"}]
ecosystems: ["go"]
tags: ["cwe-312", "infrastructure", "kubernetes", "registry", "self-hosted", "talos"]
not_affected_if: ["encrypted-support-bundles", "managed-hosting", "no-registry-auth-config"]
published_at: "2026-10-14T17:19:11+00:00"
first_seen_at: "2026-10-26T14:42:05+00:00"
updated_at: "2026-10-26T15:00:59+00:00"
sources: [{"source": "ghsa", "url": "https://github.com/advisories/GHSA-7cxh-94cf-mfp6", "first_seen_at": "2026-10-26T14:42:05+00:00"}, {"source": "nvd", "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77564", "first_seen_at": "2026-10-26T15:00:59+00:00"}]
---

# Talos Linux: Support bundle does not redact registry credentials

The talosctl support command writes private registry auth settings into the generated support bundle without redacting them. Anyone who gets a bundle and has not been given it encrypted can read those registry credentials.

_Summary, check and fix written by a model from the sources; labelled as such._

## Affected

- go:github.com/siderolabs/talos affected < 1.14.0-alpha.0.0.20260513110206-76080416beee fixed 1.14.0-alpha.0.0.20260513110206-76080416beee

## How to check

- Run `talosctl version` and compare against the fixed build listed in the advisory.
- Check whether the cluster has a `RegistryAuthConfig` resource, which the advisory says triggers the leak.
- Unpack a generated support bundle and look for `auth` fields in `resources/registryconfigs.cri.talos.dev.yaml` and `etcfilespecs.files.talos.dev.yaml`.

## Fix

- Upgrade Talos to a build at or after `1.14.0-alpha.0.0.20260513110206-76080416beee` (the fixed Go module version).
- Rotate any private registry credentials that were included in bundles already shared outside the team.
- Until upgraded, do not share support bundles publicly.

## Timeline

- 2026-10-26T14:42:05+00:00 ghsa https://github.com/advisories/GHSA-7cxh-94cf-mfp6
- 2026-10-26T15:00:59+00:00 nvd https://nvd.nist.gov/vuln/detail/CVE-2026-77564

## From the sources

### 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

---

_Free to read at a human pace. An API with keys and an MCP server are in preparation; early access: hello@infrastack.ai_