github.com/siderolabs/talos
Talos Linux is a modern Linux distribution built for Kubernetes.
View on Github
Activity
- Latest release
- 2d ago
- Total releases
- 83
- Cadence
- ~10 days
- Last 12 months
- 37
Reach
- Stars
- 11.4k
Details
- First release
- Jan 02, 2019
| Version | Released | |
|---|---|---|
v1.15.0-alpha.2
pre
|
v1.15.0-alpha.2
pre
Dependencies (184)
+ 176 more |
|
v1.14.5
patch
|
v1.14.5
patch
Dependencies (173)
+ 165 more |
|
v1.13.12
patch
1 CVE
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev |
v1.13.12
patch
Dependencies (165)
+ 157 more |
|
v1.14.4
patch
|
v1.14.4
patch
Dependencies (173)
+ 165 more |
|
v1.14.3
patch
|
v1.14.3
patch
Dependencies (173)
+ 165 more |
|
v1.15.0-alpha.1
pre
|
v1.15.0-alpha.1
pre
Dependencies (184)
+ 176 more |
|
v1.13.11
patch
1 CVE
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev |
v1.13.11
patch
Dependencies (165)
+ 157 more |
|
v1.14.2
patch
|
v1.14.2
patch
Dependencies (173)
+ 165 more |
|
v1.14.1
patch
|
v1.14.1
patch
Dependencies (172)
+ 164 more |
|
v1.15.0-alpha.0
pre
|
v1.15.0-alpha.0
pre
Dependencies (172)
+ 164 more |
|
v1.13.10
patch
1 CVE
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev |
v1.13.10
patch
Dependencies (165)
+ 157 more |
|
v1.14.0
minor
|
v1.14.0
minor
Dependencies (172)
+ 164 more |
|
v1.14.0-rc.2
pre
|
v1.14.0-rc.2
pre
Dependencies (172)
+ 164 more |
|
v1.13.9
patch
1 CVE
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev |
v1.13.9
patch
Dependencies (165)
+ 157 more |
|
v1.14.0-rc.1
pre
|
v1.14.0-rc.1
pre
Dependencies (172)
+ 164 more |
|
v1.13.8
patch
1 CVE
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev |
v1.13.8
patch
Dependencies (165)
+ 157 more |
|
v1.14.0-beta.1
pre
|
v1.14.0-beta.1
pre
Dependencies (172)
+ 164 more |
|
v1.14.0-beta.0
pre
|
v1.14.0-beta.0
pre
Dependencies (172)
+ 164 more |
|
v1.13.7
patch
1 CVE
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev |
v1.13.7
patch
Dependencies (165)
+ 157 more |
|
v1.13.6
patch
1 CVE
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev |
v1.13.6
patch
Dependencies (165)
+ 157 more |
|
v1.14.0-alpha.2
pre
|
v1.14.0-alpha.2
pre
Dependencies (169)
+ 161 more |
|
v1.13.5
patch
1 CVE
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev |
v1.13.5
patch
Dependencies (165)
+ 157 more |
|
v1.13.4
patch
1 CVE
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev |
v1.13.4
patch
Dependencies (164)
+ 156 more |
|
v1.14.0-alpha.1
pre
|
v1.14.0-alpha.1
pre
Dependencies (168)
+ 160 more |
|
v1.13.3
patch
1 CVE
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev |
v1.13.3
patch
Dependencies (165)
+ 157 more |
|
v1.13.2
patch
1 CVE
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev |
v1.13.2
patch
Dependencies (165)
+ 157 more |
|
v1.13.1
patch
1 CVE
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev |
v1.13.1
patch
Dependencies (165)
+ 157 more |
|
v1.14.0-alpha.0
pre
1 CVE
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev |
v1.14.0-alpha.0
pre
Dependencies (165)
+ 157 more |
|
v1.13.0
minor
1 CVE
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev |
v1.13.0
minor
Dependencies (164)
+ 156 more |
|
v1.12.7
minor
1 CVE
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev |
v1.12.7
minor
Dependencies (160)
+ 152 more |
|
v1.13.0-rc.0
pre
1 CVE
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev |
v1.13.0-rc.0
pre
Dependencies (164)
+ 156 more |
|
v1.13.0-beta.1
pre
1 CVE
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev |
v1.13.0-beta.1
pre
Dependencies (164)
+ 156 more |
|
v1.13.0-beta.0
pre
1 CVE
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev |
v1.13.0-beta.0
pre
Dependencies (164)
+ 156 more |
|
v1.13.0-alpha.2
pre
1 CVE
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev |
v1.13.0-alpha.2
pre
Dependencies (161)
+ 153 more |
|
v1.13.0-alpha.1
pre
1 CVE
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev |
v1.13.0-alpha.1
pre
Dependencies (163)
+ 155 more |
|
v1.13.0-alpha.0
pre
1 CVE
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev |
v1.13.0-alpha.0
pre
Dependencies (161)
+ 153 more |
|
v1.11.5
patch
2 CVEs
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev
GHSA-m38g-vww2-mvgx
May 07, 2026
Talos Linux has a local privilege escalation from untrusted workloads
7.5
/ 10
High
Local
High
Low
None
Changed
High
High
None
SummaryA vulnerability in the Linux kernel's algif_aead subsystem (CVE-2026-31431, "copy.fail") allows an unprivileged container workload to corrupt arbitrary file page-cache pages via the AF_ALG crypto interface and splice(). On Talos Linux, this vulnerability can be chained into a complete node compromise: an attacker who can schedule a pod on a worker node can, without any elevated Kubernetes permissions, achieve arbitrary code execution as root on the host (by poisoning a binary inside a privileged pod, or poisoning a binary which runs with elevated privileges like a CNI binary), access host filesystem, including node secrets. The exploit does not require kernel debugging, race conditions, or any prior privileges beyond the ability to create a pod. ImpactAn attacker with the ability to deploy a Kubernetes pod on an affected node can:
PatchesUpgrade to Talos v1.13.0 or Talos v1.12.7 which ships Linux kernel 6.18.25. The kernel fix for CVE-2026-31431 (algif_aead in-place optimization revert) was committed upstream in Linux 6.18.22 and is included in all Talos releases from v1.13.0 and Talos 1.12.7 onwards. WorkaroundsThere are multiple workarounds available based on the situation, but we really recommend to upgrade. Option 1 - Change kernel argumentsAdd a kernel argument with
Option 2 - Deploy all workload pods with a seccomp profile denying creating
|
v1.11.5
patch
Dependencies (161)
+ 153 more |
|
v1.11.1
minor
2 CVEs
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev
GHSA-m38g-vww2-mvgx
May 07, 2026
Talos Linux has a local privilege escalation from untrusted workloads
7.5
/ 10
High
Local
High
Low
None
Changed
High
High
None
SummaryA vulnerability in the Linux kernel's algif_aead subsystem (CVE-2026-31431, "copy.fail") allows an unprivileged container workload to corrupt arbitrary file page-cache pages via the AF_ALG crypto interface and splice(). On Talos Linux, this vulnerability can be chained into a complete node compromise: an attacker who can schedule a pod on a worker node can, without any elevated Kubernetes permissions, achieve arbitrary code execution as root on the host (by poisoning a binary inside a privileged pod, or poisoning a binary which runs with elevated privileges like a CNI binary), access host filesystem, including node secrets. The exploit does not require kernel debugging, race conditions, or any prior privileges beyond the ability to create a pod. ImpactAn attacker with the ability to deploy a Kubernetes pod on an affected node can:
PatchesUpgrade to Talos v1.13.0 or Talos v1.12.7 which ships Linux kernel 6.18.25. The kernel fix for CVE-2026-31431 (algif_aead in-place optimization revert) was committed upstream in Linux 6.18.22 and is included in all Talos releases from v1.13.0 and Talos 1.12.7 onwards. WorkaroundsThere are multiple workarounds available based on the situation, but we really recommend to upgrade. Option 1 - Change kernel argumentsAdd a kernel argument with
Option 2 - Deploy all workload pods with a seccomp profile denying creating
|
v1.11.1
minor
Dependencies (161)
+ 153 more |
|
v1.10.3
minor
2 CVEs
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev
GHSA-m38g-vww2-mvgx
May 07, 2026
Talos Linux has a local privilege escalation from untrusted workloads
7.5
/ 10
High
Local
High
Low
None
Changed
High
High
None
SummaryA vulnerability in the Linux kernel's algif_aead subsystem (CVE-2026-31431, "copy.fail") allows an unprivileged container workload to corrupt arbitrary file page-cache pages via the AF_ALG crypto interface and splice(). On Talos Linux, this vulnerability can be chained into a complete node compromise: an attacker who can schedule a pod on a worker node can, without any elevated Kubernetes permissions, achieve arbitrary code execution as root on the host (by poisoning a binary inside a privileged pod, or poisoning a binary which runs with elevated privileges like a CNI binary), access host filesystem, including node secrets. The exploit does not require kernel debugging, race conditions, or any prior privileges beyond the ability to create a pod. ImpactAn attacker with the ability to deploy a Kubernetes pod on an affected node can:
PatchesUpgrade to Talos v1.13.0 or Talos v1.12.7 which ships Linux kernel 6.18.25. The kernel fix for CVE-2026-31431 (algif_aead in-place optimization revert) was committed upstream in Linux 6.18.22 and is included in all Talos releases from v1.13.0 and Talos 1.12.7 onwards. WorkaroundsThere are multiple workarounds available based on the situation, but we really recommend to upgrade. Option 1 - Change kernel argumentsAdd a kernel argument with
Option 2 - Deploy all workload pods with a seccomp profile denying creating
|
v1.10.3
minor
Dependencies (159)
+ 151 more |
|
v1.9.5
minor
2 CVEs
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev
GHSA-m38g-vww2-mvgx
May 07, 2026
Talos Linux has a local privilege escalation from untrusted workloads
7.5
/ 10
High
Local
High
Low
None
Changed
High
High
None
SummaryA vulnerability in the Linux kernel's algif_aead subsystem (CVE-2026-31431, "copy.fail") allows an unprivileged container workload to corrupt arbitrary file page-cache pages via the AF_ALG crypto interface and splice(). On Talos Linux, this vulnerability can be chained into a complete node compromise: an attacker who can schedule a pod on a worker node can, without any elevated Kubernetes permissions, achieve arbitrary code execution as root on the host (by poisoning a binary inside a privileged pod, or poisoning a binary which runs with elevated privileges like a CNI binary), access host filesystem, including node secrets. The exploit does not require kernel debugging, race conditions, or any prior privileges beyond the ability to create a pod. ImpactAn attacker with the ability to deploy a Kubernetes pod on an affected node can:
PatchesUpgrade to Talos v1.13.0 or Talos v1.12.7 which ships Linux kernel 6.18.25. The kernel fix for CVE-2026-31431 (algif_aead in-place optimization revert) was committed upstream in Linux 6.18.22 and is included in all Talos releases from v1.13.0 and Talos 1.12.7 onwards. WorkaroundsThere are multiple workarounds available based on the situation, but we really recommend to upgrade. Option 1 - Change kernel argumentsAdd a kernel argument with
Option 2 - Deploy all workload pods with a seccomp profile denying creating
|
v1.9.5
minor
Dependencies (159)
+ 151 more |
|
v1.8.4
patch
2 CVEs
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev
GHSA-m38g-vww2-mvgx
May 07, 2026
Talos Linux has a local privilege escalation from untrusted workloads
7.5
/ 10
High
Local
High
Low
None
Changed
High
High
None
SummaryA vulnerability in the Linux kernel's algif_aead subsystem (CVE-2026-31431, "copy.fail") allows an unprivileged container workload to corrupt arbitrary file page-cache pages via the AF_ALG crypto interface and splice(). On Talos Linux, this vulnerability can be chained into a complete node compromise: an attacker who can schedule a pod on a worker node can, without any elevated Kubernetes permissions, achieve arbitrary code execution as root on the host (by poisoning a binary inside a privileged pod, or poisoning a binary which runs with elevated privileges like a CNI binary), access host filesystem, including node secrets. The exploit does not require kernel debugging, race conditions, or any prior privileges beyond the ability to create a pod. ImpactAn attacker with the ability to deploy a Kubernetes pod on an affected node can:
PatchesUpgrade to Talos v1.13.0 or Talos v1.12.7 which ships Linux kernel 6.18.25. The kernel fix for CVE-2026-31431 (algif_aead in-place optimization revert) was committed upstream in Linux 6.18.22 and is included in all Talos releases from v1.13.0 and Talos 1.12.7 onwards. WorkaroundsThere are multiple workarounds available based on the situation, but we really recommend to upgrade. Option 1 - Change kernel argumentsAdd a kernel argument with
Option 2 - Deploy all workload pods with a seccomp profile denying creating
|
v1.8.4
patch
Dependencies (154)
+ 146 more |
|
v1.9.0-alpha.0
pre
2 CVEs
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev
GHSA-m38g-vww2-mvgx
May 07, 2026
Talos Linux has a local privilege escalation from untrusted workloads
7.5
/ 10
High
Local
High
Low
None
Changed
High
High
None
SummaryA vulnerability in the Linux kernel's algif_aead subsystem (CVE-2026-31431, "copy.fail") allows an unprivileged container workload to corrupt arbitrary file page-cache pages via the AF_ALG crypto interface and splice(). On Talos Linux, this vulnerability can be chained into a complete node compromise: an attacker who can schedule a pod on a worker node can, without any elevated Kubernetes permissions, achieve arbitrary code execution as root on the host (by poisoning a binary inside a privileged pod, or poisoning a binary which runs with elevated privileges like a CNI binary), access host filesystem, including node secrets. The exploit does not require kernel debugging, race conditions, or any prior privileges beyond the ability to create a pod. ImpactAn attacker with the ability to deploy a Kubernetes pod on an affected node can:
PatchesUpgrade to Talos v1.13.0 or Talos v1.12.7 which ships Linux kernel 6.18.25. The kernel fix for CVE-2026-31431 (algif_aead in-place optimization revert) was committed upstream in Linux 6.18.22 and is included in all Talos releases from v1.13.0 and Talos 1.12.7 onwards. WorkaroundsThere are multiple workarounds available based on the situation, but we really recommend to upgrade. Option 1 - Change kernel argumentsAdd a kernel argument with
Option 2 - Deploy all workload pods with a seccomp profile denying creating
|
v1.9.0-alpha.0
pre
Dependencies (154)
+ 146 more |
|
v1.8.1
minor
2 CVEs
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev
GHSA-m38g-vww2-mvgx
May 07, 2026
Talos Linux has a local privilege escalation from untrusted workloads
7.5
/ 10
High
Local
High
Low
None
Changed
High
High
None
SummaryA vulnerability in the Linux kernel's algif_aead subsystem (CVE-2026-31431, "copy.fail") allows an unprivileged container workload to corrupt arbitrary file page-cache pages via the AF_ALG crypto interface and splice(). On Talos Linux, this vulnerability can be chained into a complete node compromise: an attacker who can schedule a pod on a worker node can, without any elevated Kubernetes permissions, achieve arbitrary code execution as root on the host (by poisoning a binary inside a privileged pod, or poisoning a binary which runs with elevated privileges like a CNI binary), access host filesystem, including node secrets. The exploit does not require kernel debugging, race conditions, or any prior privileges beyond the ability to create a pod. ImpactAn attacker with the ability to deploy a Kubernetes pod on an affected node can:
PatchesUpgrade to Talos v1.13.0 or Talos v1.12.7 which ships Linux kernel 6.18.25. The kernel fix for CVE-2026-31431 (algif_aead in-place optimization revert) was committed upstream in Linux 6.18.22 and is included in all Talos releases from v1.13.0 and Talos 1.12.7 onwards. WorkaroundsThere are multiple workarounds available based on the situation, but we really recommend to upgrade. Option 1 - Change kernel argumentsAdd a kernel argument with
Option 2 - Deploy all workload pods with a seccomp profile denying creating
|
v1.8.1
minor
Dependencies (153)
+ 145 more |
|
v1.8.0-beta.0
pre
2 CVEs
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev
GHSA-m38g-vww2-mvgx
May 07, 2026
Talos Linux has a local privilege escalation from untrusted workloads
7.5
/ 10
High
Local
High
Low
None
Changed
High
High
None
SummaryA vulnerability in the Linux kernel's algif_aead subsystem (CVE-2026-31431, "copy.fail") allows an unprivileged container workload to corrupt arbitrary file page-cache pages via the AF_ALG crypto interface and splice(). On Talos Linux, this vulnerability can be chained into a complete node compromise: an attacker who can schedule a pod on a worker node can, without any elevated Kubernetes permissions, achieve arbitrary code execution as root on the host (by poisoning a binary inside a privileged pod, or poisoning a binary which runs with elevated privileges like a CNI binary), access host filesystem, including node secrets. The exploit does not require kernel debugging, race conditions, or any prior privileges beyond the ability to create a pod. ImpactAn attacker with the ability to deploy a Kubernetes pod on an affected node can:
PatchesUpgrade to Talos v1.13.0 or Talos v1.12.7 which ships Linux kernel 6.18.25. The kernel fix for CVE-2026-31431 (algif_aead in-place optimization revert) was committed upstream in Linux 6.18.22 and is included in all Talos releases from v1.13.0 and Talos 1.12.7 onwards. WorkaroundsThere are multiple workarounds available based on the situation, but we really recommend to upgrade. Option 1 - Change kernel argumentsAdd a kernel argument with
Option 2 - Deploy all workload pods with a seccomp profile denying creating
|
v1.8.0-beta.0
pre
Dependencies (152)
+ 144 more |
|
v1.7.6
patch
2 CVEs
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev
GHSA-m38g-vww2-mvgx
May 07, 2026
Talos Linux has a local privilege escalation from untrusted workloads
7.5
/ 10
High
Local
High
Low
None
Changed
High
High
None
SummaryA vulnerability in the Linux kernel's algif_aead subsystem (CVE-2026-31431, "copy.fail") allows an unprivileged container workload to corrupt arbitrary file page-cache pages via the AF_ALG crypto interface and splice(). On Talos Linux, this vulnerability can be chained into a complete node compromise: an attacker who can schedule a pod on a worker node can, without any elevated Kubernetes permissions, achieve arbitrary code execution as root on the host (by poisoning a binary inside a privileged pod, or poisoning a binary which runs with elevated privileges like a CNI binary), access host filesystem, including node secrets. The exploit does not require kernel debugging, race conditions, or any prior privileges beyond the ability to create a pod. ImpactAn attacker with the ability to deploy a Kubernetes pod on an affected node can:
PatchesUpgrade to Talos v1.13.0 or Talos v1.12.7 which ships Linux kernel 6.18.25. The kernel fix for CVE-2026-31431 (algif_aead in-place optimization revert) was committed upstream in Linux 6.18.22 and is included in all Talos releases from v1.13.0 and Talos 1.12.7 onwards. WorkaroundsThere are multiple workarounds available based on the situation, but we really recommend to upgrade. Option 1 - Change kernel argumentsAdd a kernel argument with
Option 2 - Deploy all workload pods with a seccomp profile denying creating
|
v1.7.6
patch
Dependencies (147)
+ 139 more |
|
v1.7.4
minor
2 CVEs
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev
GHSA-m38g-vww2-mvgx
May 07, 2026
Talos Linux has a local privilege escalation from untrusted workloads
7.5
/ 10
High
Local
High
Low
None
Changed
High
High
None
SummaryA vulnerability in the Linux kernel's algif_aead subsystem (CVE-2026-31431, "copy.fail") allows an unprivileged container workload to corrupt arbitrary file page-cache pages via the AF_ALG crypto interface and splice(). On Talos Linux, this vulnerability can be chained into a complete node compromise: an attacker who can schedule a pod on a worker node can, without any elevated Kubernetes permissions, achieve arbitrary code execution as root on the host (by poisoning a binary inside a privileged pod, or poisoning a binary which runs with elevated privileges like a CNI binary), access host filesystem, including node secrets. The exploit does not require kernel debugging, race conditions, or any prior privileges beyond the ability to create a pod. ImpactAn attacker with the ability to deploy a Kubernetes pod on an affected node can:
PatchesUpgrade to Talos v1.13.0 or Talos v1.12.7 which ships Linux kernel 6.18.25. The kernel fix for CVE-2026-31431 (algif_aead in-place optimization revert) was committed upstream in Linux 6.18.22 and is included in all Talos releases from v1.13.0 and Talos 1.12.7 onwards. WorkaroundsThere are multiple workarounds available based on the situation, but we really recommend to upgrade. Option 1 - Change kernel argumentsAdd a kernel argument with
Option 2 - Deploy all workload pods with a seccomp profile denying creating
|
v1.7.4
minor
Dependencies (147)
+ 139 more |
|
v1.6.7
patch
2 CVEs
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev
GHSA-m38g-vww2-mvgx
May 07, 2026
Talos Linux has a local privilege escalation from untrusted workloads
7.5
/ 10
High
Local
High
Low
None
Changed
High
High
None
SummaryA vulnerability in the Linux kernel's algif_aead subsystem (CVE-2026-31431, "copy.fail") allows an unprivileged container workload to corrupt arbitrary file page-cache pages via the AF_ALG crypto interface and splice(). On Talos Linux, this vulnerability can be chained into a complete node compromise: an attacker who can schedule a pod on a worker node can, without any elevated Kubernetes permissions, achieve arbitrary code execution as root on the host (by poisoning a binary inside a privileged pod, or poisoning a binary which runs with elevated privileges like a CNI binary), access host filesystem, including node secrets. The exploit does not require kernel debugging, race conditions, or any prior privileges beyond the ability to create a pod. ImpactAn attacker with the ability to deploy a Kubernetes pod on an affected node can:
PatchesUpgrade to Talos v1.13.0 or Talos v1.12.7 which ships Linux kernel 6.18.25. The kernel fix for CVE-2026-31431 (algif_aead in-place optimization revert) was committed upstream in Linux 6.18.22 and is included in all Talos releases from v1.13.0 and Talos 1.12.7 onwards. WorkaroundsThere are multiple workarounds available based on the situation, but we really recommend to upgrade. Option 1 - Change kernel argumentsAdd a kernel argument with
Option 2 - Deploy all workload pods with a seccomp profile denying creating
|
v1.6.7
patch
Dependencies (140)
+ 132 more |
|
v1.7.0-alpha.1
pre
2 CVEs
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev
GHSA-m38g-vww2-mvgx
May 07, 2026
Talos Linux has a local privilege escalation from untrusted workloads
7.5
/ 10
High
Local
High
Low
None
Changed
High
High
None
SummaryA vulnerability in the Linux kernel's algif_aead subsystem (CVE-2026-31431, "copy.fail") allows an unprivileged container workload to corrupt arbitrary file page-cache pages via the AF_ALG crypto interface and splice(). On Talos Linux, this vulnerability can be chained into a complete node compromise: an attacker who can schedule a pod on a worker node can, without any elevated Kubernetes permissions, achieve arbitrary code execution as root on the host (by poisoning a binary inside a privileged pod, or poisoning a binary which runs with elevated privileges like a CNI binary), access host filesystem, including node secrets. The exploit does not require kernel debugging, race conditions, or any prior privileges beyond the ability to create a pod. ImpactAn attacker with the ability to deploy a Kubernetes pod on an affected node can:
PatchesUpgrade to Talos v1.13.0 or Talos v1.12.7 which ships Linux kernel 6.18.25. The kernel fix for CVE-2026-31431 (algif_aead in-place optimization revert) was committed upstream in Linux 6.18.22 and is included in all Talos releases from v1.13.0 and Talos 1.12.7 onwards. WorkaroundsThere are multiple workarounds available based on the situation, but we really recommend to upgrade. Option 1 - Change kernel argumentsAdd a kernel argument with
Option 2 - Deploy all workload pods with a seccomp profile denying creating
|
v1.7.0-alpha.1
pre
Dependencies (142)
+ 134 more |
|
v1.6.2
minor
3 CVEs
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev
GHSA-m38g-vww2-mvgx
May 07, 2026
Talos Linux has a local privilege escalation from untrusted workloads
7.5
/ 10
High
Local
High
Low
None
Changed
High
High
None
SummaryA vulnerability in the Linux kernel's algif_aead subsystem (CVE-2026-31431, "copy.fail") allows an unprivileged container workload to corrupt arbitrary file page-cache pages via the AF_ALG crypto interface and splice(). On Talos Linux, this vulnerability can be chained into a complete node compromise: an attacker who can schedule a pod on a worker node can, without any elevated Kubernetes permissions, achieve arbitrary code execution as root on the host (by poisoning a binary inside a privileged pod, or poisoning a binary which runs with elevated privileges like a CNI binary), access host filesystem, including node secrets. The exploit does not require kernel debugging, race conditions, or any prior privileges beyond the ability to create a pod. ImpactAn attacker with the ability to deploy a Kubernetes pod on an affected node can:
PatchesUpgrade to Talos v1.13.0 or Talos v1.12.7 which ships Linux kernel 6.18.25. The kernel fix for CVE-2026-31431 (algif_aead in-place optimization revert) was committed upstream in Linux 6.18.22 and is included in all Talos releases from v1.13.0 and Talos 1.12.7 onwards. WorkaroundsThere are multiple workarounds available based on the situation, but we really recommend to upgrade. Option 1 - Change kernel argumentsAdd a kernel argument with
Option 2 - Deploy all workload pods with a seccomp profile denying creating
|
v1.6.2
minor
Dependencies (136)
+ 128 more |
|
v1.6.0-alpha.1
pre
2 CVEs
CVE-2026-77564
GHSA-7cxh-94cf-mfp6
Oct 15, 2026
Talos Linux: Support bundle does not redact registry credentials
3.3
/ 10
Low
Local
Low
None
Required
Unchanged
Low
None
None
SummaryWhen generating a support bundle with DetailsWithin the generated support bundle, inside PoCSimply run ImpactThe 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. NotesTalos 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
Fixed in
1.14.0-alpha.0.0.20260513110206-76080416beee
References
Updated Oct 26, 2026 · Source: OSV.dev
GHSA-m38g-vww2-mvgx
May 07, 2026
Talos Linux has a local privilege escalation from untrusted workloads
7.5
/ 10
High
Local
High
Low
None
Changed
High
High
None
SummaryA vulnerability in the Linux kernel's algif_aead subsystem (CVE-2026-31431, "copy.fail") allows an unprivileged container workload to corrupt arbitrary file page-cache pages via the AF_ALG crypto interface and splice(). On Talos Linux, this vulnerability can be chained into a complete node compromise: an attacker who can schedule a pod on a worker node can, without any elevated Kubernetes permissions, achieve arbitrary code execution as root on the host (by poisoning a binary inside a privileged pod, or poisoning a binary which runs with elevated privileges like a CNI binary), access host filesystem, including node secrets. The exploit does not require kernel debugging, race conditions, or any prior privileges beyond the ability to create a pod. ImpactAn attacker with the ability to deploy a Kubernetes pod on an affected node can:
PatchesUpgrade to Talos v1.13.0 or Talos v1.12.7 which ships Linux kernel 6.18.25. The kernel fix for CVE-2026-31431 (algif_aead in-place optimization revert) was committed upstream in Linux 6.18.22 and is included in all Talos releases from v1.13.0 and Talos 1.12.7 onwards. WorkaroundsThere are multiple workarounds available based on the situation, but we really recommend to upgrade. Option 1 - Change kernel argumentsAdd a kernel argument with
Option 2 - Deploy all workload pods with a seccomp profile denying creating
|
v1.6.0-alpha.1
pre
Dependencies (128)
+ 120 more |