What Happened
On December 3, 2018, the Kubernetes security team disclosed CVE-2018-1002105, a critical vulnerability that allowed any authenticated user to escalate privileges and execute arbitrary code on any pod in the cluster. The flaw was in the Kubernetes API server's handling of "upgrade" requests to backend services. When a client initiated a connection upgrade (like establishing a WebSocket or streaming connection to a pod via kubectl exec), the API server would proxy the request to the kubelet but fail to re-authenticate subsequent requests in that connection. An attacker could hijack this authenticated tunnel to send arbitrary requests to the kubelet API with full privileges.
This was not a theoretical exploit. Any user with kubectl access could execute commands on nodes they shouldn't access, exfiltrate secrets, or pivot to other workloads.
Timeline
- December 3, 2018: Kubernetes security team publicly disclosed CVE-2018-1002105.
- December 5, 2018: Snyk added the vulnerability to their database with detection rules.
- Immediate response: Kubernetes project released patched versions v1.10.11, v1.11.5, v1.12.3, and v1.13.0-rc.1.
The quick release of patches suggests the Kubernetes team had advance notice and coordinated the release. However, your detection window was effectively zero unless you had already instrumented your API server to catch anomalous kubelet requests.
Which Controls Failed or Were Missing
1. Connection-level Authentication Bypass
The API server authenticated the initial upgrade request but treated the entire connection as a trusted tunnel afterward. No per-request authentication meant a single legitimate kubectl exec could become a persistent backdoor. Your RBAC policies might say "this user can exec into pods in namespace dev," but the vulnerability allowed them to exec into pods in namespace prod, kube-system, or anywhere.
2. Insufficient API Server Logging
Standard Kubernetes audit logs captured the initial connection upgrade request but didn't capture the individual API calls tunneled through that connection to the kubelet. If an attacker used this vulnerability to read secrets from etcd or modify pod specs, you'd see the entry point but not the payload. Your SIEM would show a normal kubectl exec session, not the privilege escalation that followed.
3. Missing Network Segmentation Controls
Most Kubernetes clusters allow direct API server-to-kubelet communication without additional authentication layers. This is the default configuration. The API server trusts its own authentication decisions, and the kubelet trusts requests from the API server. CVE-2018-1002105 exploited that transitive trust model. Implementing mutual TLS with certificate validation at the kubelet level could have reduced the attack surface, but that's not a standard deployment pattern.
4. No Runtime Integrity Monitoring
Even if your logging couldn't catch the tunneled requests, runtime security tools monitoring syscalls or network connections on the nodes themselves might have flagged unusual kubelet behavior. Most teams in 2018 weren't running eBPF-based runtime detection on their Kubernetes nodes. You had perimeter defenses and RBAC policies, but nothing watching what actually executed inside your cluster.
What the Relevant Standards Require
NIST 800-53: AC-3 (Access Enforcement)
This control requires enforcing approved authorizations for logical access to information and system resources. CVE-2018-1002105 violated this at the protocol level. Your RBAC policies were approved authorizations, but the API server didn't enforce them for connection-upgraded requests.
Implementation gap: AC-3 assumes your enforcement mechanism validates every access decision, not just the first one in a session. Kubernetes failed that assumption.
ISO/IEC 27001:2022: A.8.3 (Information Access Restriction)
This control requires restricting access to information and application system functions based on the access control policy. The vulnerability created an authorization bypass where users could access kubelet APIs they weren't entitled to reach.
Implementation gap: Your access control policy existed in RBAC definitions, but the enforcement layer (API server connection handling) had a logic flaw that made those policies ineffective for upgrade requests.
PCI DSS v4.0.1: Requirement 6.3.2
An inventory of bespoke and custom software, and third-party software components incorporated into bespoke and custom software is maintained to facilitate vulnerability and patch management.
If you were running Kubernetes in a PCI environment, you needed an inventory that included your Kubernetes version and a process to track security bulletins. The three-day window between disclosure and patch release was tight -- but only if you knew you were running a vulnerable version and had a deployment pipeline ready to push the update.
Implementation gap: Many teams didn't treat Kubernetes as a "software component" requiring formal vulnerability tracking. It was infrastructure, managed separately from application dependencies.
SOC 2 Type II: CC6.1 (Logical and Physical Access Controls)
The common criteria require restricting logical access through authentication and authorization mechanisms. An auditor reviewing your Kubernetes controls would've looked at RBAC policies and assumed they were enforced consistently. CVE-2018-1002105 meant your design was sound but your implementation had a bypass.
Implementation gap: Control testing should include validating that authorization checks happen at every decision point, not just session establishment. Your SOC 2 audit likely didn't include protocol-level testing of Kubernetes API flows.
Lessons and Action Items for Your Team
1. Treat Kubernetes as Application Infrastructure
Add your Kubernetes version to the same dependency tracking system you use for application libraries. Subscribe to the kubernetes-announce mailing list. When a CVE drops, you should know within an hour whether you're exposed.
Action: Add Kubernetes to your software bill of materials (SBOM). If you're using a managed service like GKE or EKS, document which version you're running and set up alerts for security bulletins.
2. Enable Comprehensive Audit Logging
The default Kubernetes audit policy logs API requests at the metadata level. That's not enough. Configure audit logging to capture request and response bodies for sensitive operations (secret access, pod exec, port-forward). Send these logs to a SIEM that can correlate API activity with node-level behavior.
Action: Implement the audit policy from the Kubernetes documentation on auditing and configure webhook backends to ship logs to your security monitoring platform in real time.
3. Deploy Runtime Security Monitoring
Tools like Falco can detect anomalous kubelet behavior even when API logs don't capture the attack vector. You want alerts when a process spawns unexpectedly, when sensitive files are accessed, or when network connections originate from unusual sources.
Action: Deploy Falco or a similar runtime security tool with rules that flag kubelet API abuse patterns. Test your detection by simulating a privilege escalation attempt in a dev cluster.
4. Implement Defense in Depth at the Network Layer
Mutual TLS between the API server and kubelet won't prevent every attack, but it raises the bar. If you're running in an environment where nodes might be compromised, require certificate-based authentication for kubelet API access.
Action: Review your kubelet configuration. Ensure --anonymous-auth=false and --authorization-mode=Webhook are set. Configure the API server to validate kubelet certificates.
5. Test Your Patch Deployment Pipeline
You had three days to patch CVE-2018-1002105 before exploit code became public. Could your team actually deploy a new Kubernetes version in that window? Most organizations couldn't -- not because the patch was hard, but because their change management process required a week of testing and approvals.
Action: Document your emergency patch procedure for Kubernetes. Run a tabletop exercise where you simulate a critical CVE disclosure and measure how long it takes to get a patch into production. If the answer is "more than 72 hours," fix your process now.
CVE-2018-1002105 wasn't the last critical Kubernetes vulnerability, and it won't be the last time a trust boundary assumption breaks down. Your controls should assume that any component in the request path -- API server, kubelet, etcd -- might have a flaw. Log everything, monitor runtime behavior, and keep your patch pipeline fast.
