Talos Linux CVE-2026-77564

Exploitation requires that a Talos operator generate a talosctl support bundle AND share it with an untrusted recipient; the bundle must include the resources registryconfigs.cri.talos.dev.yaml (containing the registry 'auth' field) and/or etcfilespecs.files.talos.dev.yaml, which on affected versions (<1.12.9, <1.13.3) are neither marked nor redacted. Realistic risk is limited by several factors: it demands privileged local/administrative use of talosctl to produce the bundle, an explicit human action to share it externally (UI:R), and the eventual impact further depends on the leaked registry's network exposure and the privileges of the exposed credentials. On Talos 1.14+ bundles are encrypted by default, further reducing but not eliminating the exposure.

This is a genuinely low-priority issue despite being a real information-disclosure flaw. All signals point the same direction: CVSS is 3.3 (Low) with vector AV:L/AC:L/PR:N/UI:R/S:U/C:L/I:N/A:N - local attack vector, required user interaction, no integrity or availability impact, and only Low confidentiality impact. There is no EPSS score, no CISA KEV listing, and no public exploit identified at time of analysis, so there is no indication of active or likely exploitation. Critically, the CVSS vector understates the real precondition: although PR:N implies no privileges, the vulnerability is only triggered when a privileged Talos operator voluntarily generates a support bundle via talosctl AND shares that bundle with an unintended party (reflected by UI:R and AV:L). The exposure is therefore operator-mediated rather than directly attacker-reachable over a network. The practical impact is bounded by the disclosed data - private container-registry authentication parameters and sensitive /etc file contents - and depends on the registry's network exposure and the privileges of the leaked credentials, which the advisory itself notes. Note also that Talos 1.14+ encrypts support bundles by default, mitigating accidental disclosure but, per the vendor, not replacing the redaction fix delivered in 1.12.9/1.13.3.

A Talos operator runs talosctl to collect a support bundle for troubleshooting and attaches it to a vendor support ticket, public GitHub issue, or shared chat. Because registry credentials from registryconfigs.cri.talos.dev.yaml and file contents from etcfilespecs.files.talos.dev.yaml are neither redacted nor marked, any recipient of that bundle obtains the private registry authentication parameters. No public exploit code exists; exploitation is passive and hinges on the operator sharing the unredacted bundle (local access, user interaction required).