CVE-2025-59836 Overview
CVE-2025-59836 is a Null Pointer Dereference vulnerability in Siderolabs Omni, a Kubernetes management platform for bare metal, virtual machines, and cloud environments. The vulnerability exists in the Omni Resource Service and allows unauthenticated attackers to cause a server panic and denial of service by sending crafted API requests with empty metadata fields.
The flaw resides in the isSensitiveSpec function which invokes grpcomni.CreateResource without performing proper validation to check if the resource's metadata field is nil. When an attacker creates a resource with an empty Metadata field, the CreateResource function attempts to dereference resource.Metadata.Version, triggering a segmentation fault and crashing the server.
Critical Impact
Unauthenticated attackers can remotely crash Omni servers managing Kubernetes clusters, causing service disruption across bare metal, VM, and cloud deployments without requiring any credentials.
Affected Products
- Siderolabs Omni versions prior to 1.1.5
- Siderolabs Omni versions prior to 1.0.2
- All Omni deployments using the vulnerable gRPC API endpoints
Discovery Timeline
- October 13, 2025 - CVE-2025-59836 published to NVD
- December 4, 2025 - Last updated in NVD database
Technical Details for CVE-2025-59836
Vulnerability Analysis
This vulnerability (CWE-476: NULL Pointer Dereference) occurs due to insufficient input validation in the Omni Resource Service's gRPC API layer. The isSensitiveSpec function processes resource creation and update requests without validating that required metadata structures are present before accessing their properties.
When the server receives a request to create or update a resource, it passes the request to grpcomni.CreateResource. This function expects the resource object to contain a properly initialized Metadata field with a Version property. However, if an attacker sends a request with an empty or nil Metadata field, the code attempts to access resource.Metadata.Version on a nil pointer, causing an immediate segmentation fault.
The vulnerability is particularly dangerous because it can be triggered by unauthenticated users, requiring no prior authentication or authorization to exploit. This allows any network-accessible attacker to repeatedly crash the Omni server, effectively denying service to legitimate Kubernetes management operations.
Root Cause
The root cause is missing nil pointer validation in the gRPC interceptor chain before processing resource creation and update operations. The isSensitiveSpec function and underlying CreateResource implementation assume that incoming request objects will always contain properly structured metadata, violating the principle of defensive programming.
The fix involved updating the go-api-signature dependency to version 0.3.8, which includes proper validation logic in the gRPC interceptor chain to reject requests with nil or empty metadata fields before they can trigger the null pointer dereference.
Attack Vector
The attack can be executed remotely over the network without authentication. An attacker simply needs to:
- Identify an exposed Omni API endpoint
- Craft a gRPC request to the resource creation or update endpoints
- Include an empty or nil Metadata field in the request payload
- Send the request to trigger the server crash
The following patch was applied to fix the vulnerability by updating the go-api-signature dependency:
github.com/siderolabs/discovery-client v0.1.13
github.com/siderolabs/discovery-service v1.0.11
github.com/siderolabs/gen v0.8.5
- github.com/siderolabs/go-api-signature v0.3.7
+ github.com/siderolabs/go-api-signature v0.3.8
github.com/siderolabs/go-circular v0.2.3
github.com/siderolabs/go-debug v0.6.0
github.com/siderolabs/go-kubernetes v0.2.25
Source: GitHub Commit 1396083f
Detection Methods for CVE-2025-59836
Indicators of Compromise
- Unexpected Omni server crashes or restarts with segmentation fault errors in logs
- gRPC API requests to resource creation/update endpoints containing empty or missing Metadata fields
- Repeated connection attempts to Omni API endpoints followed by server process terminations
- Kubernetes management operations failing due to Omni service unavailability
Detection Strategies
- Monitor Omni server logs for panic messages containing "nil pointer dereference" or "invalid memory address"
- Implement gRPC request inspection to identify malformed requests with empty metadata structures
- Configure alerting on Omni service restarts or crashes occurring in short succession
- Deploy network-level monitoring to detect suspicious traffic patterns to Omni API ports
Monitoring Recommendations
- Enable verbose logging on Omni servers to capture gRPC request details before crashes
- Implement health checks to detect and alert on Omni service availability issues
- Monitor process crash dumps for signatures matching nil pointer dereference in resource handling code
- Track API request patterns for anomalous empty or malformed payloads
How to Mitigate CVE-2025-59836
Immediate Actions Required
- Upgrade Siderolabs Omni to version 1.1.5 or 1.0.2 immediately
- Restrict network access to Omni API endpoints to trusted networks only
- Implement rate limiting on gRPC API endpoints to reduce impact of potential exploitation
- Review logs for evidence of exploitation attempts before patching
Patch Information
Siderolabs has released patched versions that address this vulnerability by fixing the order in the gRPC interceptor chain and updating the go-api-signature dependency to version 0.3.8. The fix ensures proper validation of request metadata before processing.
Patched versions:
- Omni version 1.1.5 for the 1.1.x branch
- Omni version 1.0.2 for the 1.0.x branch
For detailed patch information, refer to the GitHub Security Advisory GHSA-4p3p-cr38-v5xp.
Workarounds
- Deploy a reverse proxy or API gateway in front of Omni to validate request structure before forwarding
- Implement network segmentation to limit access to Omni API endpoints to authorized clients only
- Use firewall rules to restrict inbound connections to the Omni gRPC port from untrusted networks
- Consider temporary service isolation until patches can be applied in production environments
# Example: Restrict access to Omni API port using iptables
iptables -A INPUT -p tcp --dport 8080 -s 10.0.0.0/8 -j ACCEPT
iptables -A INPUT -p tcp --dport 8080 -j DROP
# Verify Omni version after upgrade
omnictl version
# Expected output should show 1.1.5 or 1.0.2
Disclaimer: This content was generated using AI. While we strive for accuracy, please verify critical information with official sources.
