Unfixed Kubernetes CVEs: What You Can and Can't Actually Detect

Four Kubernetes CVEs from 2020–2021 will not be patched. Not because they’ve been overlooked — the Kubernetes Security Response Committee updated the records on June 1, 2026 — but because “fixing the underlying behavior in code would break existing Kubernetes functionality.” Your scanner will confirm the affected version. It won’t tell you whether your cluster is actually exposed.

The Framework

Standard vulnerability scanners make a binary determination: does this cluster run an affected Kubernetes version? For these four CVEs, that answer is almost always yes. The meaningful question — does your specific cluster configuration create the conditions required for exploitation? — requires a different approach.

Datadog’s guidance centers on Kubernetes audit logs: monitoring API activity and configuration changes for the specific preconditions each CVE requires, rather than signature-based detection that can only confirm version exposure.

CVE-2020-8554 — Service Traffic Redirection

What it enables: An attacker with permission to create or modify Services can redirect traffic to arbitrary IPs via the externalIPs field.

What to monitor: API calls that submit resources containing spec.externalIPs or patch Service status endpoints. Any submission containing this field from an unexpected principal warrants immediate review. RBAC restrictions on Service creation or modification are the preventive control.

CVE-2021-25740 — Endpoint Manipulation

What it enables: Endpoint objects can be manipulated to route traffic across namespace boundaries in ways that bypass network policy intent.

What to monitor: Who is modifying Endpoints or EndpointSlice objects, and from which namespaces. Audit logs capture this activity; however, they cannot confirm whether cross-namespace traffic routing actually occurred as a result. Network policies should restrict what traffic can flow between namespaces regardless.

CVE-2020-8561 — Webhook and Logging Manipulation

What it enables: Webhook configuration changes or increased API server logging verbosity can be used to capture sensitive API server traffic.

What to monitor: Changes to webhook configurations and API server verbosity flags via /debug/flags/v. Unexpected modifications from non-controller principals are the detection signal. Webhook configuration changes should be gated behind admission controllers.

CVE-2020-8562 — DNS Rebinding

What it enables: Attacks can leverage DNS rebinding to access the API server through proxy endpoints that bypass address validation.

What to monitor: Proxy requests blocked by address validation in audit logs. Exploitation cannot be confirmed through logs alone, but unusual proxy access patterns signal investigation.

Where It Doesn’t Apply

This framework is detection, not remediation. For clusters running multitenant workloads where an untrusted tenant could create Services or modify Endpoints, audit log monitoring is a compensating control — necessary but insufficient. The architectural remediation is restricting RBAC permissions so that the preconditions for exploitation don’t exist in the first place.

For clusters with full trust between all workloads (internal tooling, single-tenant environments), the residual risk from these CVEs is materially lower — the preconditions for exploitation require a compromised or malicious internal principal, which is a different threat model than public-facing multitenant infrastructure.

Source: Datadog Engineering

Content created with AI assistance and reviewed for accuracy.