Focus on siderolabs vulnerabilities and metrics.
Last updated: 16 Jan 2026, 23:25 UTC
This page consolidates all known Common Vulnerabilities and Exposures (CVEs) associated with siderolabs. We track both calendar-based metrics (using fixed periods) and rolling metrics (using gliding windows) to give you a comprehensive view of security trends and risk evolution. Use these insights to assess risk and plan your patching strategy.
For a broader perspective on cybersecurity threats, explore the comprehensive list of CVEs by vendor and product. Stay updated on critical vulnerabilities affecting major software and hardware providers.
Total siderolabs CVEs: 4
Earliest CVE date: 13 Sep 2022, 17:15 UTC
Latest CVE date: 13 Oct 2025, 21:15 UTC
Latest CVE reference: CVE-2025-61688
30-day Count (Rolling): 0
365-day Count (Rolling): 3
Calendar-based Variation
Calendar-based Variation compares a fixed calendar period (e.g., this month versus the same month last year), while Rolling Growth Rate uses a continuous window (e.g., last 30 days versus the previous 30 days) to capture trends independent of calendar boundaries.
Month Variation (Calendar): 0%
Year Variation (Calendar): 0%
Month Growth Rate (30-day Rolling): 0.0%
Year Growth Rate (365-day Rolling): 0.0%
Average CVSS: 0.0
Max CVSS: 0
Critical CVEs (≥9): 0
| Range | Count |
|---|---|
| 0.0-3.9 | 4 |
| 4.0-6.9 | 0 |
| 7.0-8.9 | 0 |
| 9.0-10.0 | 0 |
These are the five CVEs with the highest CVSS scores for siderolabs, sorted by severity first and recency.
Omni manages Kubernetes on bare metal, virtual machines, or in a cloud. Prior to 1.1.5 and 1.0.2, Omni might leak sensitive information via an API.
Omni manages Kubernetes on bare metal, virtual machines, or in a cloud. Prior to 1.1.5 and 1.0.2, there is a nil pointer dereference vulnerability in the Omni Resource Service allows unauthenticated users to cause a server panic and denial of service by sending empty create/update resource requests through the API endpoints. The vulnerability exists in the isSensitiveSpec function which calls grpcomni.CreateResource without checking if the resource's metadata field is nil. When a resource is created with an empty Metadata field, the CreateResource function attempts to access resource.Metadata.Version causing a segmentation fault. This vulnerability is fixed in 1.1.5 and 1.0.2.
Omni manages Kubernetes on bare metal, virtual machines, or in a cloud. Prior to version 0.48.0, Omni Wireguard SideroLink has the potential to escape. Omni and each Talos machine establish a peer-to-peer (P2P) SideroLink connection using WireGuard to mutually authenticate and authorize access. The WireGuard interface on Omni is configured to ensure that the source IP address of an incoming packet matches the IPv6 address assigned to the Talos peer. However, it performs no validation on the packet's destination address. The Talos end of the SideroLink connection cannot be considered a trusted environment. Workloads running on Kubernetes, especially those configured with host networking, could gain direct access to this link. Therefore, a malicious workload could theoretically send arbitrary packets over the SideroLink interface. This issue has been patched in version 0.48.0.
Talos Linux is a Linux distribution built for Kubernetes deployments. Talos worker nodes use a join token to get accepted into the Talos cluster. Due to improper validation of the request while signing a worker node CSR (certificate signing request) Talos control plane node might issue Talos API certificate which allows full access to Talos API on a control plane node. Accessing Talos API with full level access on a control plane node might reveal sensitive information which allows full level access to the cluster (Kubernetes and Talos PKI, etc.). Talos API join token is stored in the machine configuration on the worker node. When configured correctly, Kubernetes workloads don't have access to the machine configuration, but due to a misconfiguration workload might access the machine configuration and reveal the join token. This problem has been fixed in Talos 1.2.2. Enabling the Pod Security Standards mitigates the vulnerability by denying hostPath mounts and host networking by default in the baseline policy. Clusters that don't run untrusted workloads are not affected. Clusters with correct Pod Security configurations which don't allow hostPath mounts, and secure access to cloud metadata server (or machine configuration is not supplied via cloud metadata server) are not affected.