Skip to main content
CVE Vulnerability Database
Vulnerability Database/CVE-2025-59824

CVE-2025-59824: Siderolabs Omni Privilege Escalation

CVE-2025-59824 is a privilege escalation vulnerability in Siderolabs Omni affecting WireGuard SideroLink connections. Malicious workloads can exploit inadequate packet validation to send arbitrary traffic. This article covers technical details, affected versions, impact analysis, and mitigation strategies.

Updated:

CVE-2025-59824 Overview

CVE-2025-59824 affects Siderolabs Omni, a management platform for Kubernetes clusters running on bare metal, virtual machines, or cloud infrastructure. Omni establishes peer-to-peer SideroLink connections with Talos machines using WireGuard for mutual authentication and authorization. The WireGuard interface on Omni validates the source IPv6 address of incoming packets against the assigned Talos peer address. It performs no validation on the packet destination address. A malicious workload running on Talos, especially one configured with host networking, could send arbitrary packets over the SideroLink interface. The issue is classified as an authorization flaw [CWE-863] and was patched in Omni version 0.48.0.

Critical Impact

A malicious Kubernetes workload with host networking access on a Talos node can send arbitrary packets across the SideroLink WireGuard tunnel to unintended destinations reachable through Omni.

Affected Products

  • Siderolabs Omni versions prior to 0.48.0
  • Deployments using WireGuard-based SideroLink peer connections
  • Talos machines managed by vulnerable Omni instances

Discovery Timeline

  • 2025-09-24 - CVE-2025-59824 published to NVD
  • 2026-06-17 - Last updated in NVD database

Technical Details for CVE-2025-59824

Vulnerability Analysis

Omni and each Talos machine form a peer-to-peer SideroLink connection using WireGuard. WireGuard cryptographically authenticates each peer and binds a specific IPv6 address to that peer. Omni enforces this binding for the source address of incoming packets but does not filter the destination address of those packets. The Talos endpoint of the tunnel is not a trusted boundary. Kubernetes workloads scheduled on Talos nodes, particularly Pods running with hostNetwork: true, can reach the SideroLink interface directly. Such a workload can craft packets destined for arbitrary IPs and inject them into the tunnel. Omni will forward or process those packets because destination filtering is missing. The upstream fix lives in the siderolink library, upgraded from v0.3.12 to v0.3.13, which adds validation of incoming packet destination addresses in the siderolink manager.

Root Cause

The root cause is an improper authorization check [CWE-863] in the SideroLink packet handling logic. Source address validation was implemented, but destination address validation against the expected Omni-side address was not. This asymmetric validation allowed traffic scoped only by peer identity, not by intended recipient.

Attack Vector

Exploitation requires an attacker to already control a workload on a managed Talos node with host networking privileges. The attacker crafts IPv6 packets on the SideroLink interface with a valid source address but arbitrary destination addresses. Because the network attack path requires high privileges and existing tenancy on a Talos node, exploit complexity is high and no public proof of concept is available.

text
// Patch reference: bump siderolink dependency (go.mod)
	github.com/siderolabs/kms-client v0.1.0
	github.com/siderolabs/omni/client v0.45.0
	github.com/siderolabs/proto-codec v0.1.2
-	github.com/siderolabs/siderolink v0.3.12
+	github.com/siderolabs/siderolink v0.3.13
	github.com/siderolabs/talos/pkg/machinery v1.10.0-alpha.0

Source: Siderolabs Omni commit a5efd81

Detection Methods for CVE-2025-59824

Indicators of Compromise

  • Unexpected outbound IPv6 traffic on the SideroLink WireGuard interface directed at addresses other than the Omni endpoint.
  • Kubernetes Pods on Talos nodes configured with hostNetwork: true that do not have a documented operational reason.
  • Omni or Talos logs showing dropped or malformed packets after upgrading to 0.48.0 where the new destination validation is enforced.

Detection Strategies

  • Audit Kubernetes manifests across managed clusters for workloads requesting host networking and evaluate whether that privilege is justified.
  • Capture traffic on the SideroLink interface on Omni and compare destination addresses against the expected Omni-side IPv6 address.
  • Correlate Talos machine identity, Pod scheduling events, and SideroLink packet counters to identify anomalous senders.

Monitoring Recommendations

  • Alert on the creation of Pods with hostNetwork: true, hostPID: true, or elevated securityContext privileges on Talos nodes.
  • Track version inventory of Omni installations and flag any instance below 0.48.0.
  • Monitor WireGuard peer statistics for unusual packet volume or destination diversity per Talos peer.

How to Mitigate CVE-2025-59824

Immediate Actions Required

  • Upgrade Omni to version 0.48.0 or later, which includes the patched siderolink v0.3.13 library that validates incoming packet destination addresses.
  • Inventory all Talos nodes and confirm which workloads currently use host networking, then remove the privilege where it is not required.
  • Apply Kubernetes admission controls, such as Pod Security Admission at the restricted level, to prevent unauthorized host networking use.

Patch Information

The fix is delivered in Omni 0.48.0 by upgrading the github.com/siderolabs/siderolink module from v0.3.12 to v0.3.13. The upstream change adds destination address validation in the siderolink manager. Full details are available in the Siderolabs Omni GitHub Security Advisory GHSA-hqrf-67pm-wgfq and the remediation commit.

Workarounds

  • Restrict which service accounts and namespaces can schedule workloads with hostNetwork: true on Talos nodes.
  • Apply network policies and node-level firewall rules to constrain traffic sourced from workloads that share the host network namespace.
  • Segment Omni management networks so that traffic egressing the SideroLink tunnel cannot reach sensitive internal systems.
bash
# Verify installed Omni version and upgrade path
omnictl version
# Upgrade Omni to the patched release (example using Helm)
helm upgrade omni siderolabs/omni --version 0.48.0
# Enforce restricted Pod Security on namespaces hosting untrusted workloads
kubectl label namespace <ns> \
  pod-security.kubernetes.io/enforce=restricted \
  pod-security.kubernetes.io/enforce-version=latest

Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.

Default Legacy - Prefooter | Experience the World’s Most Advanced Cybersecurity Platform

Experience the Most Advanced Cybersecurity Platform

See how the world’s most intelligent, autonomous cybersecurity platform can protect your organization today and into the future.