CVE-2026-24005: Kruise for Kubernetes SSRF Vulnerability

CVE-2026-24005 Overview

CVE-2026-24005 is a Server-Side Request Forgery (SSRF) vulnerability in OpenKruise, a Kubernetes automation management tool designed for large-scale application deployments. The vulnerability exists in the PodProbeMarker component, which allows defining custom probes with TCPSocket or HTTPGet handlers. The webhook validation fails to restrict the Host field in these probe configurations, enabling attackers to perform SSRF attacks from the node network namespace.

Critical Impact

Attackers with PodProbeMarker creation permission can exploit this vulnerability to trigger SSRF from Kubernetes nodes, perform internal port scanning, and receive response feedback through NodePodProbe status messages.

Affected Products

• OpenKruise versions prior to 1.8.3
• OpenKruise versions prior to 1.7.5
• Kubernetes clusters running vulnerable OpenKruise deployments with hostNetwork=true on kruise-daemon

Discovery Timeline

• 2026-02-25 - CVE-2026-24005 published to NVD
• 2026-02-25 - Last updated in NVD database

Technical Details for CVE-2026-24005

Vulnerability Analysis

This vulnerability is classified as CWE-918 (Server-Side Request Forgery). The core issue stems from missing input validation in the PodProbeMarker webhook handler. When users define custom probes using TCPSocket or HTTPGet handlers, the webhook validation logic does not enforce restrictions on the Host field within these configurations.

Since the kruise-daemon component operates with hostNetwork=true, all probe executions occur within the node's network namespace rather than a containerized network. This configuration grants probes direct access to the node's network stack, including internal services, cloud metadata endpoints, and other sensitive network resources that should not be accessible from within Kubernetes pods.

An attacker who has been granted PodProbeMarker creation permissions can craft malicious probe configurations specifying arbitrary Host values. When these probes execute, they effectively leverage the node's network position to reach internal infrastructure components. The NodePodProbe status messages provide response feedback to the attacker, enabling enumeration and reconnaissance of internal network services.

Root Cause

The root cause is the absence of validation logic for the Host field in TCPSocket and HTTPGet probe configurations within the pkg/webhook/podprobemarker/validating/probe_create_update_handler.go file. The original implementation of validateTCPSocketAction only validated the port field, allowing any arbitrary host to be specified without restriction.

Attack Vector

The attack vector is network-based and requires the attacker to have PodProbeMarker creation permissions within the Kubernetes cluster. The exploitation flow involves:

1. Creating a PodProbeMarker resource with a TCPSocket or HTTPGet probe specifying a target Host value (e.g., internal services, cloud metadata endpoints like 169.254.169.254)
2. The kruise-daemon executes the probe from the node network namespace
3. The attacker observes probe results through NodePodProbe status messages to determine connectivity and response characteristics
4. This enables internal port scanning and service discovery from the perspective of the Kubernetes node

// Security patch for validateTCPSocketAction function
// Source: https://github.com/openkruise/kruise/commit/94364b76adf3e8a1749a31afe809a163bed29613
 }
 
 func validateTCPSocketAction(tcp *corev1.TCPSocketAction, fldPath *field.Path) field.ErrorList {
-	return ValidatePortNumOrName(tcp.Port, fldPath.Child("port"))
+	allErrors := field.ErrorList{}
+	if len(tcp.Host) > 0 {
+		allErrors = append(allErrors, field.Invalid(fldPath.Child("host"), tcp.Host, "host field in probes is not allowed"))
+	}
+
+	allErrors = append(allErrors, ValidatePortNumOrName(tcp.Port, fldPath.Child("port"))...)
+
+	return allErrors
 }
 
 var supportedHTTPSchemes = sets.New(corev1.URISchemeHTTP, corev1.URISchemeHTTPS)

Source: GitHub Commit Update

Detection Methods for CVE-2026-24005

Indicators of Compromise

• PodProbeMarker resources with non-empty Host fields in TCPSocket or HTTPGet probe configurations
• Unusual network traffic originating from kruise-daemon pods to internal services or metadata endpoints
• NodePodProbe status messages indicating probe connections to unexpected internal IP addresses

Detection Strategies

• Audit existing PodProbeMarker resources for probe configurations specifying arbitrary Host values using kubectl get podprobemarkers -A -o yaml
• Monitor Kubernetes audit logs for PodProbeMarker creation and update events with suspicious probe configurations
• Implement network policies to restrict egress traffic from kruise-daemon pods to expected destinations

Monitoring Recommendations

• Deploy network monitoring to detect kruise-daemon connections to cloud metadata endpoints (e.g., 169.254.169.254)
• Enable Kubernetes audit logging for all PodProbeMarker resource operations
• Alert on NodePodProbe status messages that reference unexpected internal IP ranges or service ports

How to Mitigate CVE-2026-24005

Immediate Actions Required

• Upgrade OpenKruise to version 1.8.3 or 1.7.5 immediately to apply the security patch
• Review and audit all existing PodProbeMarker resources for malicious Host field configurations
• Restrict PodProbeMarker creation permissions using Kubernetes RBAC to limit exposure

Patch Information

The vulnerability has been patched in OpenKruise versions 1.8.3 and 1.7.5. The fix adds validation logic to reject any TCPSocket or HTTPGet probe configurations that specify a Host field value. For detailed patch information, refer to the GitHub Security Advisory GHSA-9fj4-3849-rv9g.

Patched releases are available:

• OpenKruise v1.8.3
• OpenKruise v1.7.5

Workarounds

• Implement strict RBAC policies to limit which users and service accounts can create or modify PodProbeMarker resources
• Deploy admission controllers (such as OPA Gatekeeper or Kyverno) to validate and reject PodProbeMarker resources with Host fields specified
• Apply network policies to restrict kruise-daemon egress traffic to only necessary destinations

# Configuration example - Restrict PodProbeMarker creation with RBAC
# Create a ClusterRole that denies PodProbeMarker creation for untrusted users
kubectl create clusterrole deny-podprobemarker --verb=get,list --resource=podprobemarkers.apps.kruise.io

# Bind the restricted role to specific users or groups
kubectl create clusterrolebinding restricted-ppm-access --clusterrole=deny-podprobemarker --group=untrusted-developers