
Loading

Loading
We use strictly necessary cookies to run this site, and analytics cookies to understand how it's used. See our Privacy Policy for details.
A GitHub-reviewed security advisory, not necessarily under active exploitation the way our CISA KEV advisories are, but a real, disclosed vulnerability in an open-source dependency.
Affected packages
Vulnerable: < 1.14.0-alpha.0.0.20260513110206-76080416beee
Patched in 1.14.0-alpha.0.0.20260513110206-76080416beee
Details
When generating a support bundle with talosctl support the credentials entered for private registries are included in the bundle.
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.
Simply run talosctl -n [...] support on a cluster with a RegistryAuthConfig resource
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.
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.
EPSS, exploit probability
Low0.13%
estimated chance of real-world exploitation in the next 30 days, higher than 2.5% of every CVE FIRST.org scores
Refreshed 10/15/2026, via FIRST.org's EPSS model, not CVSS, this measures likelihood of exploitation, not how severe it would be.
Talk to us about this
Find out whether this dependency (or others like it) is actually reachable in your codebase.
Get help patching, or building dependency-scanning into your pipeline going forward.
A secure code review or supply chain review finds this before an advisory does.