Understanding Unfixed Kubernetes CVEs: What You Can — and Can't — Detect

Understanding Unfixed Kubernetes CVEs: What You Can — and Can't — Detect

Enterprise Developer Platforms

Some Kubernetes CVEs won’t be patched — not because they’re low severity, but because the fix would break Kubernetes. Four CVEs fall into this category, and they’ve sat open for years. The right response isn’t to wait for a patch that isn’t coming. It’s to understand exactly what your cluster’s exposure is, and what audit logs can and can’t tell you about exploitation.

The Framework

The core distinction Datadog’s analysis draws is between affected version and exposed cluster. Most clusters running an affected Kubernetes version are not actually exploitable — each of these CVEs requires a specific combination of permissions, cluster features, and network access to reach. The detection framework has two phases: confirm whether your cluster meets the conditions for exploitation, and monitor audit logs for activity patterns that indicate those conditions are being exercised.

Audit logs identify who made configuration changes. They cannot confirm successful exploitation in all cases. Additional evidence from network, DNS, or process logs may be necessary for full investigation.

CVE-2020-8554 — Service Traffic Redirection

Condition for exposure: A user with service creation privileges and network access to ClusterIP services. This CVE allows an attacker with these permissions to redirect traffic by setting spec.externalIPs on a service.

Detection query: Monitor for services create or patch operations that return HTTP 2xx:

@apiVersion:audit.k8s.io/v1 @objectRef.resource:services
(@verb:create OR @verb:patch) @responseStatus.code:[200 TO 299]

Additions of spec.externalIPs and patches to services/status are the specific patterns to alert on.

CVE-2021-25740 — Endpoint Manipulation

Condition for exposure: A user with permissions to create or modify Endpoints or EndpointSlices. This allows cross-namespace traffic redirection by pointing an endpoint at a service in another namespace.

Detection approach: Monitor writes to Endpoints and EndpointSlices from identities outside the expected set for each namespace. Audit logs surface who modified the endpoint resource — confirming whether traffic actually crossed namespace boundaries requires network flow data in addition to audit log evidence.

CVE-2020-8561 — Webhook and Log Data Exposure

Condition for exposure: A user with permissions to modify webhook configurations or API server verbosity settings. This allows sensitive data exfiltration through webhook callbacks or verbose logging.

Detection approach: Track webhook configuration changes and API server verbosity modifications. Datadog notes that “examining kube-apiserver log responses is the only known way to detect successful exploitation” — audit logs identify configuration changes but not whether exfiltration occurred.

CVE-2020-8562 — DNS Rebinding via kube-proxy

Condition for exposure: A user with Nodes/proxy permissions and the ability to influence DNS resolution. This enables SSRF through the kube-apiserver proxy.

Detection approach: Monitor for “address not allowed” responses in kube-proxy logs, which indicate blocked DNS rebinding attempts. Confirming successful exploitation requires DNS query logs in addition to audit evidence.

Where This Framework Breaks Down

Audit logs are authorization-layer telemetry. They record what the API server allowed or denied; they don’t record what network traffic occurred as a result. For CVEs where the attack is complete at the API server level (CVE-2020-8554), audit logs are sufficient. For CVEs where the attack requires downstream behavior to succeed (CVE-2020-8562 requires the DNS rebinding to actually redirect traffic), audit logs are necessary but not sufficient.

The Datadog recommendation: document your exposure assessment per CVE — cluster conditions, preventive controls in place, what the detection query covers and doesn’t cover. Kubernetes observability and alerting pipelines built for autoscaling and performance also provide the audit infrastructure these detections rely on.

The So What

The action for platform teams is straightforward: run the exposure check for each of these four CVEs against your cluster’s current configuration, implement the audit log queries for any where conditions are met, and document the gaps where audit logs alone can’t confirm exploitation. The CVEs aren’t going away. The detection coverage is the only meaningful response available.

Source: Datadog

Content created with AI assistance and reviewed for accuracy.

💬

Join the conversation

Stack Insiders is our free community for readers who want to go deeper — share resources, ask questions, and connect with others across every vertical we cover.

Join Stack Insiders →

Newsletter coming soon.

Curated digests across AI, biohacking, photography, travel, and more. Be the first to know when we launch.