Skip to content

Talos Linux: Support bundle does not redact registry credentials

Low severity GitHub Reviewed Published Aug 24, 2026 in siderolabs/talos • Updated Oct 26, 2026

Package

gomod github.com/siderolabs/talos (Go)

Affected versions

< 1.14.0-alpha.0.0.20260513110206-76080416beee

Patched versions

1.14.0-alpha.0.0.20260513110206-76080416beee

Description

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

References

@smira smira published to siderolabs/talos Aug 24, 2026
Published by the National Vulnerability Database Oct 14, 2026
Published to the GitHub Advisory Database Oct 15, 2026
Reviewed Oct 15, 2026
Last updated Oct 26, 2026

Severity

Low

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Local
Attack complexity
Low
Privileges required
None
User interaction
Required
Scope
Unchanged
Confidentiality
Low
Integrity
None
Availability
None

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N

EPSS score

Exploit Prediction Scoring System (EPSS)

This score estimates the probability of this vulnerability being exploited within the next 30 days. Data provided by FIRST.
(3rd percentile)

Weaknesses

Cleartext Storage of Sensitive Information

The product stores sensitive information in cleartext within a resource that might be accessible to another control sphere. Learn more on MITRE.

CVE ID

CVE-2026-77564

GHSA ID

GHSA-7cxh-94cf-mfp6

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.