GHSA-7cxh-94cf-mfp6: Low severity go/github.com/talos-systems/talos vulnerability
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
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
go/github.com/talos-systems/talosto a version that resolves this vulnerability.Fixed in 1.14.0-alpha.0.0.20260513110206-76080416beee - Upgrade
Upgrade
Talosto a version that resolves this vulnerability.Fixed in 1.14+
Event History
Frequently Asked Questions
Which environments are exposed to credential disclosure?
Clusters with a RegistryAuthConfig resource are affected when a support bundle is generated with talosctl support. The bundle retains the resource's auth field in resources/registryconfigs.cri.talos.dev.yaml and etcfilespecs.files.talos.dev.yaml.
How could an attacker obtain the registry credentials?
An attacker would need access to a generated support.zip bundle containing the affected files. Risk arises when bundles have been uploaded to GitHub issues, Slack threads, public forums, or otherwise shared with unintended parties.
What is the practical impact if a bundle was publicly shared?
The exposed data may reveal authentication parameters for a private registry. If the registry is publicly accessible and those credentials allow writes, the stated consequences include denial of service, data loss, tag hijacking, and possible supply-chain compromise.
What can be done before a fix is available?
Avoid sharing support bundles without reviewing them for registry credentials. In particular, inspect or redact the auth values in resources/registryconfigs.cri.talos.dev.yaml and etcfilespecs.files.talos.dev.yaml before distributing a bundle.