GHSA-7CXH-94CF-MFP6
Vulnerability from github – Published: 2026-10-15 20:20 – Updated: 2026-10-15 20:20Summary
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": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/talos-systems/talos"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.14.0-alpha.0.0.20260513110206-76080416beee"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-77564"
],
"database_specific": {
"cwe_ids": [
"CWE-312"
],
"github_reviewed": true,
"github_reviewed_at": "2026-10-15T20:20:16Z",
"nvd_published_at": "2026-10-14T17:19:11Z",
"severity": "LOW"
},
"details": "### Summary\nWhen generating a support bundle with `talosctl support` the credentials entered for private registries are included in the bundle.\n\n\n### Details\n\nWithin the generated support bundle, inside `resources/registryconfigs.cri.talos.dev.yaml` the `auth` field of the spec is retained.\nThe same, potentially sensitive information is present within `etcfilespecs.files.talos.dev.yaml`.\n\n### PoC\n\nSimply run `talosctl -n [...] support` on a cluster with a `RegistryAuthConfig` resource \n\n### Impact\n\nThe 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.\n\nIn 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.\n\n\n### Notes\n\nTalos 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.\n\n### Environment\n\n- Talos version: v1.13.0\n- Kubernetes version: 1.35.3\n- Platform: amd64",
"id": "GHSA-7cxh-94cf-mfp6",
"modified": "2026-10-15T20:20:16Z",
"published": "2026-10-15T20:20:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/siderolabs/talos/security/advisories/GHSA-7cxh-94cf-mfp6"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-77564"
},
{
"type": "WEB",
"url": "https://github.com/siderolabs/talos/pull/13345"
},
{
"type": "WEB",
"url": "https://github.com/siderolabs/talos/pull/13434"
},
{
"type": "WEB",
"url": "https://github.com/siderolabs/talos/pull/13611"
},
{
"type": "WEB",
"url": "https://github.com/siderolabs/talos/commit/4c288caf2de1db7f84bba0539ca5ed7d6ecb9142"
},
{
"type": "WEB",
"url": "https://github.com/siderolabs/talos/commit/76080416beee6460375c0d0db3cab76cc493ad3e"
},
{
"type": "WEB",
"url": "https://github.com/siderolabs/talos/commit/7dc716d850e43373ba8702c702105f4edd68fceb"
},
{
"type": "PACKAGE",
"url": "https://github.com/siderolabs/talos"
},
{
"type": "WEB",
"url": "https://github.com/siderolabs/talos/releases/tag/v1.12.9"
},
{
"type": "WEB",
"url": "https://github.com/siderolabs/talos/releases/tag/v1.13.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Talos Linux: Support bundle does not redact registry credentials"
}
Drag nodes to arrange them. Double-click a related vulnerability to open it, or a source to visit its link. The Physics button on the left tunes the layout and the simulation; the legend at the bottom left hides or shows nodes by kind and by sighting type.
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.
Vulnerability timeline
Sightings and recorded dates, grouped by day · UTC
Loading timeline…
The approach is described in our paper Mapping CVEs to MITRE ATT&CK Techniques: A Curated Gold-Set Classifier and the Limits of LLM-Assisted Label Expansion.
Browse all ATT&CK techniques and the vulnerabilities related to each.
Related by attack behaviour
Vulnerabilities whose description is nearest to this one in the vector space of the CIRCL/vulnerability-attack-technique-biencoder model. This is a similarity search over the bi-encoder space (plain cosine), not a classification, and it has no measured accuracy.