--- title: CVE in the heart of Kubernetes apiserver | daily.dev description: A critical authentication bypass vulnerability, CVE-2018-1002105, was disclosed in the Kubernetes apiserver on December 3, 2018, scoring near-maximum severity... canonical: https://daily.dev/posts/cve-in-the-heart-of-kubernetes-apiserver-lsu8femtk twitter:card: summary_large_image twitter:site: @dailydotdev og:type: website og:site_name: daily.dev og:title: CVE in the heart of Kubernetes apiserver | daily.dev og:description: A critical authentication bypass vulnerability, CVE-2018-1002105, was disclosed in the Kubernetes apiserver on December 3, 2018, scoring near-maximum severity... og:url: https://daily.dev/posts/cve-in-the-heart-of-kubernetes-apiserver-lsu8femtk og:image: https://api.daily.dev/og/posts/lsu8Femtk.png og:image:alt: CVE in the heart of Kubernetes apiserver og:image:width: 1200 og:image:height: 630 og:locale: en --- > ## Documentation Index > Fetch the complete documentation index at: https://daily.dev/llms.txt > Use this file to discover all available pages before exploring further. # CVE in the heart of Kubernetes apiserver **[Teleport](https://daily.dev/sources/teleport)** · 7 min read · 0 upvotes · 0 comments ## Summary A critical authentication bypass vulnerability, CVE-2018-1002105, was disclosed in the Kubernetes apiserver on December 3, 2018, scoring near-maximum severity on the CVSS scale. The bug stems from how the apiserver handles websocket upgrade requests to aggregated backend services: if the upgrade fails, the apiserver could incorrectly treat the connection as successfully bridged, letting an attacker send follow-up requests that masquerade as the authenticated master apiserver, bypassing security and audit controls. Disabling anonymous API access does not fully protect clusters, since any authenticated user with exec access to a pod could exploit the flaw to escalate privileges across the cluster. All mainline Kubernetes releases (1.10.x, 1.11.x, 1.12.x, 1.13.0) now include the 37-line fix, and major managed offerings (GKE, EKS, AKS) were patched by their providers. A proof-of-concept vulnerability checker is provided for administrators to test whether their clusters remain exposed. ## Full article daily.dev links to this article rather than hosting it. Read it at the original source: ## Questions this post answers ### What is CVE-2018-1002105 and how does it bypass Kubernetes authentication? CVE-2018-1002105 is a Kubernetes apiserver authentication bypass vulnerability caused by improper handling of websocket upgrade connections to aggregated backend services. If a proxied websocket upgrade request fails, the apiserver could mistakenly treat it as successful, leaving a half-open authenticated connection that a client could reuse to send further requests, effectively masquerading as the master apiserver and bypassing security and audit controls. _Track critical infrastructure CVEs like this one on daily.dev before they hit your production clusters._ ### Which Kubernetes versions fix CVE-2018-1002105? The fix landed in all current mainline releases at the time: v1.10.x, 1.11.x, 1.12.x, and 1.13.0, via a 37-line patch that makes the apiserver verify the result of the proxied upgrade connection before bridging it. Vendors with long-term support policies also cherry-picked the fix into older, unsupported branches, and managed offerings like GKE, AKS, and EKS were patched by their providers. _Developers patching Kubernetes clusters can follow security fixes like this via daily.dev._ ### If I disable anonymous access to the Kubernetes API, am I still vulnerable to CVE-2018-1002105? Yes, disabling anonymous access only limits exploitation to authenticated users rather than eliminating the risk. Any authenticated kubectl user permitted to exec into a pod, even one restricted to their own namespace, could exploit the bug to exec into any pod handled by the same kubelet, then pivot toward the cluster control plane and escalate to broader privileges. _Cluster operators weighing mitigation trade-offs can follow deep-dive security writeups on daily.dev._ ## Similar posts on daily.dev - [Reconciling the Past: Correcting Records for Unfixed Kubernetes CVEs](https://daily.dev/posts/reconciling-the-past-correcting-records-for-unfixed-kubernetes-cves-vtna1rmxv) · Kubernetes · 0 upvotes · 0 comments - [CVE-2026-82329: Unauthenticated Administrative Access in…](https://daily.dev/posts/cve-2026-82329-unauthenticated-administrative-access-in--jp5ers0bt) · Sliver C2 Documentation · 0 upvotes · 0 comments - [Understanding unfixed Kubernetes CVEs: What you can and can’t detect](https://daily.dev/posts/understanding-unfixed-kubernetes-cves-what-you-can-and-can-t-detect-mrbleofgj) · Datadog · 0 upvotes · 0 comments --- Tags: [#kubernetes](https://daily.dev/tags/kubernetes) [View this post on daily.dev](https://daily.dev/posts/cve-in-the-heart-of-kubernetes-apiserver-lsu8femtk) ```json {"@context":"https://schema.org","@graph":[{"@type":"Organization","@id":"https://daily.dev/#organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180},"sameAs":["https://twitter.com/dailydotdev","https://github.com/dailydotdev","https://www.linkedin.com/company/daily-dev-ltd"]},{"@type":"WebSite","@id":"https://daily.dev/#website","url":"https://daily.dev","name":"daily.dev","publisher":{"@id":"https://daily.dev/#organization"},"potentialAction":{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https://daily.dev/search?q={search_term_string}"},"query-input":"required name=search_term_string"}}]} {"@context":"https://schema.org","@type":"TechArticle","headline":"CVE in the heart of Kubernetes apiserver","url":"https://daily.dev/posts/cve-in-the-heart-of-kubernetes-apiserver-lsu8femtk","mainEntityOfPage":{"@type":"WebPage","@id":"https://daily.dev/posts/cve-in-the-heart-of-kubernetes-apiserver-lsu8femtk"},"datePublished":"2026-08-23T12:19:45.775Z","dateModified":"2026-08-23T12:39:56.038Z","description":"A critical authentication bypass vulnerability, CVE-2018-1002105, was disclosed in the Kubernetes apiserver on December 3, 2018, scoring near-maximum severity...","image":"https://media.daily.dev/image/upload/s--OHB84bZF--/f_auto/v1722860399/public/Placeholder%2010","thumbnailUrl":"https://media.daily.dev/image/upload/s--OHB84bZF--/f_auto/v1722860399/public/Placeholder%2010","isAccessibleForFree":true,"articleSection":"Teleport","inLanguage":"en","publisher":{"@type":"Organization","name":"daily.dev","url":"https://daily.dev","logo":{"@type":"ImageObject","url":"https://daily.dev/apple-touch-icon.png","width":180,"height":180}},"author":{"@type":"Organization","name":"Teleport","logo":"https://media.daily.dev/image/upload/s--Dw-Bbw6O--/c_limit,w_256/f_auto,q_auto/v1787487494/logos/teleport?_a=BAMAMicg0","url":"https://daily.dev/sources/teleport"},"commentCount":0,"discussionUrl":"https://daily.dev/posts/cve-in-the-heart-of-kubernetes-apiserver-lsu8femtk","interactionStatistic":[{"@type":"InteractionCounter","interactionType":{"@type":"LikeAction"},"userInteractionCount":0},{"@type":"InteractionCounter","interactionType":{"@type":"CommentAction"},"userInteractionCount":0}],"keywords":"kubernetes","timeRequired":"PT7M"} {"@context":"https://schema.org","@type":"BreadcrumbList","itemListElement":[{"@type":"ListItem","position":1,"name":"Home","item":"https://daily.dev"},{"@type":"ListItem","position":2,"name":"Teleport","item":"https://daily.dev/sources/teleport"},{"@type":"ListItem","position":3,"name":"CVE in the heart of Kubernetes apiserver"}]} {"@context":"https://schema.org","@type":"FAQPage","@id":"https://daily.dev/posts/cve-in-the-heart-of-kubernetes-apiserver-lsu8femtk#faq","mainEntity":[{"@type":"Question","name":"What is CVE-2018-1002105 and how does it bypass Kubernetes authentication?","acceptedAnswer":{"@type":"Answer","text":"CVE-2018-1002105 is a Kubernetes apiserver authentication bypass vulnerability caused by improper handling of websocket upgrade connections to aggregated backend services. If a proxied websocket upgrade request fails, the apiserver could mistakenly treat it as successful, leaving a half-open authenticated connection that a client could reuse to send further requests, effectively masquerading as the master apiserver and bypassing security and audit controls. Track critical infrastructure CVEs like this one on daily.dev before they hit your production clusters."}},{"@type":"Question","name":"Which Kubernetes versions fix CVE-2018-1002105?","acceptedAnswer":{"@type":"Answer","text":"The fix landed in all current mainline releases at the time: v1.10.x, 1.11.x, 1.12.x, and 1.13.0, via a 37-line patch that makes the apiserver verify the result of the proxied upgrade connection before bridging it. Vendors with long-term support policies also cherry-picked the fix into older, unsupported branches, and managed offerings like GKE, AKS, and EKS were patched by their providers. Developers patching Kubernetes clusters can follow security fixes like this via daily.dev."}},{"@type":"Question","name":"If I disable anonymous access to the Kubernetes API, am I still vulnerable to CVE-2018-1002105?","acceptedAnswer":{"@type":"Answer","text":"Yes, disabling anonymous access only limits exploitation to authenticated users rather than eliminating the risk. Any authenticated kubectl user permitted to exec into a pod, even one restricted to their own namespace, could exploit the bug to exec into any pod handled by the same kubelet, then pivot toward the cluster control plane and escalate to broader privileges. Cluster operators weighing mitigation trade-offs can follow deep-dive security writeups on daily.dev."}}]} ```