CVE-2026-24005
SSRF Vulnerability in Kruise PodProbeMarker Enables Node Network Attacks
Publication date: 2026-02-25
Last updated on: 2026-03-05
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| openkruise | kruise | to 1.7.5 (exc) |
| openkruise | kruise | From 1.8.0 (inc) to 1.8.3 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-918 | The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
[{'type': 'paragraph', 'content': "CVE-2026-24005 is a Server-Side Request Forgery (SSRF) vulnerability in the OpenKruise project's PodProbeMarker component. The issue arises because the webhook validation does not restrict the 'Host' field in custom probes defined with TCPSocket or HTTPGet handlers. Since the kruise-daemon runs with hostNetwork=true, it executes these probes from the node's network namespace. An attacker with permission to create PodProbeMarker resources can specify arbitrary Host values, causing the node to make network requests to internal or node-local addresses. This allows the attacker to perform SSRF attacks, port scanning, and receive feedback through NodePodProbe status messages."}, {'type': 'paragraph', 'content': "The vulnerability is due to improper input validation of the 'Host' field in probe configurations, which was previously allowed but is now disallowed in fixed versions. The fix involves adding validation checks in the webhook to reject any probe configuration specifying a non-empty 'Host' field, preventing exploitation."}] [1, 3]
How can this vulnerability impact me? :
This vulnerability can impact you by allowing an attacker with PodProbeMarker creation permissions to perform SSRF attacks from the node network namespace. Specifically, the attacker can:
- Trigger probes that connect to arbitrary node-local or internal IP addresses and ports.
- Perform port scanning and service discovery on internal services such as kubelet health endpoints, cloud metadata services, or other internal network resources.
- Receive detailed feedback about probe success or failure through NodePodProbe status messages, enabling further reconnaissance.
The impact includes potential unauthorized access to sensitive internal services (confidentiality impact), limited integrity impact, and possible resource consumption affecting availability.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
I don't know
How can this vulnerability be detected on my network or system? Can you suggest some commands?
[{'type': 'paragraph', 'content': 'This vulnerability can be detected by auditing PodProbeMarker resources in your Kubernetes cluster to identify any probes that specify a non-empty "host" field in TCPSocket or HTTPGet handlers. Since the kruise-daemon runs with hostNetwork=true and executes these probes from the node network namespace, probes with arbitrary Host values can be indicators of exploitation attempts.'}, {'type': 'paragraph', 'content': 'You can check for PodProbeMarker resources with probes that have the "host" field set by querying the Kubernetes API or using kubectl commands to inspect the probe configurations.'}, {'type': 'list_item', 'content': 'kubectl get podprobemarkers --all-namespaces -o json | jq \'.items[] | select(.spec.probe.tcpSocket.host != "" or .spec.probe.httpGet.host != "")\''}, {'type': 'list_item', 'content': 'kubectl describe podprobemarker <name> -n <namespace> to manually inspect the probe configuration for suspicious host fields.'}, {'type': 'paragraph', 'content': 'Additionally, monitoring NodePodProbe status messages for unusual connection success or failure feedback to internal or node-local IP addresses can help detect active exploitation or port scanning attempts.'}] [3]
What immediate steps should I take to mitigate this vulnerability?
Immediate mitigation steps include restricting PodProbeMarker creation permissions to trusted users only, to prevent attackers from creating malicious probes with arbitrary Host fields.
Apply network policies to limit the egress traffic of the kruise-daemon, preventing it from reaching sensitive internal or node-local services.
Audit existing PodProbeMarker resources for probes specifying non-empty Host fields and remove or update them to comply with the security best practices.
Upgrade OpenKruise to versions 1.8.3 or 1.7.5 or later, where the webhook validation enforces restrictions disallowing the Host field in probes, effectively preventing this vulnerability.