Kubernetes API server privilege escalation via aggregated API (CVE-2018-1002105)

In December 2018, the Kubernetes Product Security Committee disclosed one of the most severe vulnerabilities ever found in the platform's control plane: CVE-2018-1002105, a privilege escalation flaw in the API server's aggregation layer. The bug allowed any authenticated user — and in many misconfigured clusters, any unauthenticated network client — to send specially crafted requests that the API server would forward to a backend extension server using the API server's own fully-privileged TLS credentials. The practical result was full cluster-admin access with almost no attacker skill required: no exploit chain, no memory corruption, just a malformed HTTP upgrade request. Given how central the API server is to every Kubernetes control decision — scheduling, secrets, RBAC, network policy — this vulnerability effectively handed attackers the keys to the entire cluster.

What the vulnerability actually does

Kubernetes' aggregation layer lets cluster operators register additional "extension" API servers (things like metrics-server, service-catalog, or custom CRDs-backed APIs) that appear to clients as native parts of the Kubernetes API. The main kube-apiserver proxies matching requests to these backends over an authenticated, trusted connection.

The flaw was in how that proxying handled certain subresource requests — specifically exec, attach, portforward, and other requests that trigger a protocol upgrade to a streaming connection. Discovered by Rancher Labs engineer Darren Shepherd, the exploit worked roughly like this:

1. An attacker sends a request to the API server for a valid API resource, but crafts it to trigger a specific error response from the backend during the connection-upgrade handshake.
2. Because of a bug in error handling, the API server leaves the underlying TCP connection to the backend open rather than tearing it down.
3. The attacker then sends additional, arbitrary requests directly over that already-open, already-authenticated connection.
4. The backend server sees those follow-up requests as coming from the trusted API server identity — not from the original unprivileged caller — and processes them with the API server's own credentials, which are typically cluster-admin equivalent.

In short: authenticate once as a low-privileged user, then smuggle unauthenticated commands through a channel the backend believes is coming from the most trusted actor in the cluster. Any cluster running an extension API server (which is extremely common — metrics-server ships by default in many managed Kubernetes offerings) was exposed, and no special permissions beyond basic API access were needed to trigger it.

Affected versions and components

The vulnerability affects the kube-apiserver component in any Kubernetes cluster where the aggregation layer is enabled with at least one registered extension APIService — which, again, is the default configuration in most production and managed clusters (EKS, GKE, AKS, OpenShift, and self-managed distributions all typically ship with aggregated APIs enabled).

Specifically vulnerable releases:

• All Kubernetes 1.7.x through 1.9.x branches (the aggregation layer's entire supported lifetime up to that point)
• Kubernetes 1.10.x prior to 1.10.11
• Kubernetes 1.11.x prior to 1.11.5
• Kubernetes 1.12.x prior to 1.12.3
• Kubernetes 1.13.0 prior to release candidate 1.13.0-rc.1

Because the flaw lived in core kube-apiserver proxy logic rather than in any specific extension API, it was distribution-agnostic — OpenShift, Rancher, and other Kubernetes-based platforms carried their own advisories and backports on the same timeline.

Severity: CVSS, EPSS, and KEV context

CVE-2018-1002105 carries a CVSS v3.0 base score of 9.8 (Critical), reflecting network-exploitable access, low attack complexity, no privileges required in many configurations, and complete compromise of confidentiality, integrity, and availability. It is one of a small handful of Kubernetes CVEs to reach the top of the CVSS scale, alongside vulnerabilities like the kubectl cp path traversal issues and various ingress-controller flaws.

This CVE predates the EPSS (Exploit Prediction Scoring System) program's mainstream adoption, and public EPSS tracking for vulnerabilities of this vintage is sparse. Given the trivial exploitation path, network accessibility, and the fact that working proof-of-concept exploit code was published within days of disclosure, a vulnerability with this profile would score very high under current EPSS models if actively re-evaluated. It is not currently listed in CISA's Known Exploited Vulnerabilities (KEV) catalog, which tracks confirmed in-the-wild exploitation rather than theoretical severity — but the absence from KEV should not be read as low risk. KEV coverage skews toward internet-facing software with documented incident telemetry, and Kubernetes control-plane compromises inside private clusters are far less likely to generate the kind of public incident reporting that drives KEV additions. Security teams should treat the CVSS 9.8 rating, not KEV absence, as the operative signal here.

Timeline

• Discovery: Darren Shepherd of Rancher Labs identifies the flaw during aggregation-layer testing and privately reports it to the Kubernetes Product Security Committee.
• Coordinated disclosure prep: The committee works with maintainers to develop and stage patches across all supported release branches simultaneously, a process typical for embargoed Kubernetes security issues.
• December 3, 2018 — Public disclosure and patch release: Kubernetes 1.10.11, 1.11.5, 1.12.3, and 1.13.0-rc.1 are released with the fix. The CVE is published, and the security committee's advisory goes out to the kubernetes-announce mailing list and distribution vendors.
• December 2018 — Downstream advisories: Managed Kubernetes providers (EKS, GKE, AKS) and platform vendors (OpenShift, Rancher) issue their own patch guidance and, in several cases, force upgrades or apply mitigations on customers' behalf given the severity.
• Following weeks: Public proof-of-concept exploitation writeups circulate, and security researchers publish detection guidance for audit-log signatures associated with the attack pattern (notably a spike in connection-upgrade errors followed by unexpected proxied requests).

Remediation steps

1. Patch immediately. Upgrade kube-apiserver (and any bundled control-plane components) to at least 1.10.11, 1.11.5, 1.12.3, or 1.13.0-rc.1 (or newer). This is the only complete fix — everything below is a mitigation for clusters that cannot patch on short notice.
2. Inventory your aggregation layer. Run kubectl get apiservices and identify every registered extension API server. Any cluster with entries beyond the built-in Kubernetes APIs is exposed until patched.
3. If you cannot patch immediately, disable unnecessary aggregated APIs. Removing or disabling extension APIService objects that aren't strictly required (temporarily) removes the exploitable proxy path, at the cost of losing that functionality until you can patch.
4. Tighten RBAC around exec/attach/portforward. Since the exploit chain relies on triggering the connection-upgrade path, restricting which principals can invoke these subresources reduces the population of users who can attempt the attack, though it does not eliminate the underlying flaw.
5. Review audit logs for the attack signature. Look for connection-upgrade requests that return errors immediately followed by unexpected proxied traffic to extension API servers from the same client session — a pattern consistent with exploitation attempts.
6. Rotate credentials post-patch if you suspect exploitation. Because a successful exploit grants effective cluster-admin, treat any suspected exploitation as a full control-plane compromise: rotate service account tokens, TLS certificates, and any secrets the API server had access to, and audit for persistence (new RBAC bindings, added service accounts, modified admission webhooks).
7. Verify managed-cluster patch status explicitly. If you run on EKS, GKE, or AKS, confirm the control-plane version reported by your provider reflects a patched release — control-plane patching schedules vary by provider and region, and this is not something customers can always self-remediate.

How Safeguard Helps

CVE-2018-1002105 is a textbook case for why version inventory alone isn't enough — the real risk hinges on whether your clusters actually run an aggregation layer with extension API servers registered, and whether the vulnerable code path is reachable from workloads with untrusted input. Safeguard's reachability analysis correlates your infrastructure-as-code and runtime cluster inventory against known-vulnerable kube-apiserver versions to tell you precisely which clusters are exposed versus merely running an old version number with the aggregation layer disabled. Griffin AI, Safeguard's detection engine, continuously watches for the connection-upgrade-then-proxy attack signature in Kubernetes audit logs, flagging exploitation attempts in real time rather than relying on after-the-fact log review. Our SBOM generation and ingest pipeline tracks control-plane and extension API server versions across every cluster in your fleet, so a critical advisory like this one surfaces immediately as an inventory match rather than a manual audit exercise. And where a fix is available, Safeguard's auto-fix PR workflow can open the version-bump change against your cluster provisioning repositories automatically, cutting the time between advisory and patched control plane from days to hours.