CVE-2018-1002105: The First Critical Kubernetes Security Vulnerability Explained

This article is based on reporting originally published by Naked Security (Sophos) on 5 December 2018.

Background: What Is Kubernetes?

Kubernetes is an open-source container orchestration platform originally created by Google and now maintained by the Cloud Native Computing Foundation (CNCF), part of the Linux Foundation. It is one of the most widely deployed pieces of infrastructure in modern cloud-native environments.

Unlike virtual machines, which include a complete guest operating system, containers package only the application code and its dependencies, sharing the host OS kernel. This makes them lightweight and portable, but it also means that a security breach in the container management layer can have wide-reaching consequences across an entire cluster.

Kubernetes groups containers into logical units called pods and provides scheduling, scaling, networking, and lifecycle management for those pods across fleets that can number in the tens or hundreds of thousands.

CVE-2018-1002105: The First Critical Kubernetes Vulnerability

In December 2018, the Kubernetes security team disclosed CVE-2018-1002105, the first vulnerability in the project to receive a critical severity rating. The flaw resided in the Kubernetes API server — the central control plane component that processes all instructions sent to a cluster via HTTP.

How Normal API Server Authentication Works

Under normal operation, the Kubernetes API server authenticates every incoming request — typically using certificate-based authentication — before forwarding it to the appropriate backend or pod. This gating mechanism is what separates authorised operators from everyone else.

How the Exploit Worked

CVE-2018-1002105 was a privilege-escalation vulnerability triggered by a flaw in the way the API server handled error responses when proxying connections to backend pods:

1. An attacker sent a specially crafted, malformed request to the Kubernetes API server — one designed to generate an error response from a backend pod.
2. Rather than closing the connection after the error, the API server left the HTTP connection to the pod open.
3. Subsequent requests sent over that same open connection were forwarded to the pod without any further authorisation checks.
4. The attacker effectively gained the same level of access as a fully privileged user, regardless of their actual permissions.

This unauthorised access extended to exec-level privileges — the ability to execute commands inside any container on the affected node, including containers with read/write access to the host filesystem.

Two Exploit Variants

The vulnerability had two distinct attack paths:

• Aggregated API servers: Exploitable by any authenticated user, including those with minimal permissions. This made it the more dangerous variant from an exposure standpoint.
• Exec/attach/port-forward API calls: Required the attacker to already hold admin or edit role-level access, making this variant slightly less severe but still significant in multi-tenant environments.

Potential Impact

Once an attacker successfully exploited CVE-2018-1002105, they could:

• Steal data — including secrets, credentials, and application data flowing between workloads.
• Execute arbitrary commands inside any running container on the compromised node.
• Read or modify the host filesystem if the targeted container had that level of access.
• Disrupt services by killing pods or corrupting workloads.
• Pivot laterally within the cluster to compromise additional nodes and workloads.

Affected Components and Distributions

Because Kubernetes is used as a foundational layer in many managed and self-hosted distributions, the blast radius of this vulnerability was significant. Red Hat confirmed that OpenShift version 3.x — which uses Kubernetes as a core component — was affected by the flaw. Other distributions and managed services built on Kubernetes were similarly impacted and issued their own advisories.

Remediation

The Kubernetes project released a patch addressing CVE-2018-1002105 promptly after disclosure. The recommended actions at the time of disclosure were:

• Apply the patch immediately. Clusters that supported automated upgrades were protected once the patch was applied.
• Manually upgrade any self-managed Kubernetes installations that do not auto-update.
• Review audit logs for unexpected API server connections or privilege escalation attempts that may indicate prior exploitation.
• Harden RBAC policies to limit the number of users and service accounts with aggregated API server access.
• Check your distribution’s advisory — OpenShift, GKE, AKS, EKS and other managed platforms each published specific guidance and patching timelines.

Lessons for Kubernetes Operators

CVE-2018-1002105 served as a wake-up call for the Kubernetes community on several fronts:

• No software is immune. Even a mature, heavily audited project like Kubernetes can harbour critical flaws. Treat Kubernetes as you would any other piece of critical infrastructure from a patch management perspective.
• Least-privilege RBAC matters. Restricting which users and service accounts can access aggregated API servers and exec endpoints limits the exploitability of vulnerabilities of this class.
• Enable audit logging. Kubernetes API server audit logs would have been the primary forensic tool for detecting exploitation of this vulnerability in production.
• Monitor for anomalous API activity. Unexpected exec calls or unusual connection patterns from low-privileged accounts are red flags worth alerting on.

Further Reading

• Original Naked Security (Sophos) report on CVE-2018-1002105
• Cloud Native Computing Foundation (CNCF)