Understanding & Securing Kubernetes: Key Vulnerabilities

Updated on November 11, 2026

For security teams, Kubernetes isn’t just another box to check. While this dynamic system is often the core of modern cloud deployments, its vulnerabilities aren’t static. New issues appear suddenly and from a mix of factors — complexity in configuration, rapid innovation, and a vast ecosystem of tools and extensions. New attack vectors also emerge as organizations adopt advanced features, integrate third-party tools, or scale their workloads. 

How can teams even start to understand patterns among these types of vulnerabilities? And how do they secure them efficiently? While we’ve already covered Kubernetes runtime security, this article will take a 35,000-foot approach: we’ll look at broader patterns among Kubernetes vulnerabilities and offer actionable tips for securing this dynamic business tool.

Understanding Kubernetes Vulnerabilities

Kubernetes (often called K8s) is an open-source platform for deploying, scaling, and managing containers. Containerized applications contain everything they need to run, including code, libraries, and dependencies, and Kubernetes eases their path, handling how they run across clusters of machines, ensuring high availability and easy scaling.

The flexibility, usability, and adaptability that have made Kubernetes a cornerstone of cloud computing also introduce significant security challenges. Kubernetes is not secure by default. For example, network policies that control traffic between pods are not enforced unless explicitly configured. Similarly, Role-Based Access Control (RBAC), which restricts access to resources, must be enabled and tailored to limit permissions. While Kubernetes includes security features like these, it leaves them disabled or minimally configured out of the box, requiring security teams to take deliberate steps to activate and customize protections to secure their environments effectively.

And those insecure elements can have a substantial impact on the security of entire cloud-native environments. For instance, an exposed cluster that’s been misconfigured or doesn’t have basic security measures deployed could leave the door open for threat actors to cause damage or move laterally to exfiltrate critical data. 

Ultimately, Kubernetes vulnerabilities result from its default openness, reliance on user-driven configuration, and the complexity of managing its rapidly evolving ecosystem.

Kubernetes vulnerabilities fall into four categories: 

• Misconfigurations that can lead to compromise because of inaccurately deployed Kubernetes environments. These are often unintentional vulnerabilities caused by setup complexity. 
• Access control issues like admin rights provided to the wrong user or higher permissions provided to clusters than necessary. 
• Known software issues in the Kubernetes control plane or pods that can enable a threat actor to gain a foothold and escalate privileges or trigger a container breakout. 
• Environment-level vulnerabilities that relate to weaknesses in the host system underpinning the Kubernetes environment. This is especially pertinent for self-hosted Kubernetes environments. Using a hosted Kubernetes as a Service (KaaS) means that cloud providers take it upon themselves to keep the underlying architecture secure. 

Its open-source environment makes Kubernetes simultaneously more and less secure. The number of contributors is vast, spanning people across the globe, including developers at some of the largest brands. This means that, in theory, major vulnerabilities can be identified and a fix pushed relatively quickly. However, the evolving threat landscape includes more attacks on cloud environments and associated technologies like Kubernetes. This means that security teams must ensure they have deployed best practices to secure their Kubernetes at build-time and runtime to limit the risk of any single vulnerability causing issues. 

Critical Kubernetes Vulnerabilities

Kubernetes has rapidly grown in popularity, becoming the de facto standard for container orchestration in cloud-native environments.

Kubernetes is one of the most popular containerization platforms, with 84% of companies using containers and 78% of those opting for Kubernetes.

Kubernetes’ popularity, while a testament to its utility, has also made it an appealing target for attackers. This increased exposure has amplified the need for organizations to understand potential vulnerabilities within Kubernetes environments and how they can be exploited. As adoption grows, so does the complexity of managing and securing these environments, underscoring the importance of proactively identifying weaknesses.

As we dive into the most critical vulnerability types, it’s important to remember that, regardless of type, not all Kubernetes vulnerabilities are created equal. 

Some may not have the same potential impact on the organization if successfully exploited. Others may have their impact mitigated if other security tools have been deployed effectively. Categories aren’t indicative of criticality. Instead, they offer insight into the most common “doors” that attackers use to gain entrance to the environment.

Configuration vulnerabilities

Kubernetes is a very flexible container orchestration platform. As a result, there are plenty of configurations in the system that need to be set up correctly for the environment to remain secure and containers to remain isolated. 

Configuration vulnerabilities are of greater concern with self-hosted implementations; KaaS providers resolve many of these issues automatically. 

Authentication and authorization flaws

This class of flaws includes issues like weak authentication mechanisms, improper management of service accounts, lack of multi-factor authentication, misconfigured access controls, and poorly handled secrets. Sensitive information should never be stored in container images or application code. It belongs in external key and secret management systems, encrypted in transit and at rest. Authentication flaws can lead to unauthorized access to the cluster, allowing attackers to potentially compromise workloads or exfiltrate sensitive data.

Container escape vulnerabilities

Containers should be isolated from each other when running on Kubernetes. This protects containers from any issues from another container and keeps the host secure against threats. If containers are improperly isolated, this could lead to a container escape that allows threat actors to compromise the host system and move laterally into other containers or systems in the technology infrastructure. 

Network security weaknesses

Because it is a cloud-deployed solution, getting network defenses right is a key facet of protecting Kubernetes against compromise, and a restrictive approach works best. Network policies should deny traffic by default and allow only explicitly permitted connections. This class of vulnerabilities includes overly open or missing network policies, issues in network routers, inaccurate network traffic monitoring, and incorrectly exposed network-accessible assets. 

Supply chain vulnerabilities

A supply chain vulnerability in Kubernetes refers to a weakness in building and deploying container images, where malicious code or vulnerable dependencies can be introduced at any stage, potentially allowing attackers to gain unauthorized access to Kubernetes workloads.  

Control Plane Vulnerability Types

Not every Kubernetes weakness is a misconfiguration. Some are flaws in core components, and the control plane is where those flaws reach furthest.

Authorization and access-control bypass

A request succeeds even though RBAC, policy, or admission logic should have blocked it. These flaws appear in the kube-apiserver, aggregated API server paths, and admission plugins. They stem from incorrect authorization checks, scope handling, or policy enforcement logic. Examples include CVE-2022-3162 (unauthorized read of custom resources) and CVE-2024-3177 (bypassing the mountable secrets policy imposed by the ServiceAccount admission plugin). Indicators include unexpected access to resources and policy decisions that don’t match intent. The blast radius can be cluster-wide data exposure or unauthorized control over APIs and policies. First step: patch the affected component and verify RBAC and admission policy enforcement.

Denial of service

Malformed input, parser exhaustion, or unbounded processing exhausts CPU, memory, or request-processing capacity in central components. Examples include CVE-2019-11253 (API server JSON/YAML parsing vulnerable to resource exhaustion), CVE-2019-11254 (malicious YAML payloads), CVE-2020-8552 (apiserver out-of-memory), and CVE-2025-0426 (node denial of service via the kubelet Checkpoint API). Indicators include API latency spikes, apiserver crashes or memory spikes, and admission timeouts. The blast radius is a cluster-wide outage or degraded control plane. First step: upgrade to a fixed version and restrict the triggering request path where possible.

API server proxy abuse

CVE-2018-1002105 was the first critical CVE in the Kubernetes project. It came from the way the kube-apiserver proxied connection upgrade requests to backend services. An attacker could gain remote access to those services and execute arbitrary commands on them, which could lead to privilege escalation. Insecure defaults made it worse, because both authenticated and unauthenticated users were allowed to query the Kubernetes API. First step: upgrade to a fixed version.

High-Impact CVEs in Kubernetes

Since its introduction in 2014, Kubernetes has had hundreds of identified vulnerabilities added to the Common Vulnerabilities and Exposures (CVE) database. In 2024 alone, dozens of vulnerabilities of all severity levels joined them. These CVEs mostly relate to external tools that integrate with Kubernetes rather than Kubernetes itself. This should come as little surprise, given the popularity of Kubernetes with container orchestration. 

Here are some of the best-known and impactful Kubernetes vulnerabilities:

These vulnerabilities represent some of the most significant risks in Kubernetes environments, spanning both core components and external integrations. While Kubernetes offers features for container orchestration, its complexity and flexibility often introduce opportunities for misconfigurations, exploitation, and weak security practices. Understanding these vulnerabilities—and why they matter—helps security teams prioritize their efforts.

Here’s why these Kubernetes vulnerabilities matter:

API Server Exploits (CVE-2019-11247)

This vulnerability exploited flaws in Kubernetes’ Role-Based Access Control (RBAC) configuration. If RBAC permissions were not properly set, users with limited access could escalate privileges, gaining access to more cluster resources than intended.

The API server is the central control plane of Kubernetes. Any compromise here gives attackers the ability to manipulate critical cluster operations. This vulnerability highlighted the risks of default or overly permissive RBAC configurations.

Pod Security Bypass (CVE-2020-8554)

This vulnerability allowed attackers to manipulate Kubernetes’ network policies to intercept traffic between pods or external clients. By assigning IPs maliciously, attackers could redirect traffic and perform man-in-the-middle attacks.

Network policies are a core feature for ensuring secure communication between Kubernetes resources. A bypass like this compromises pod isolation and could lead to data theft or unauthorized data exposure. Attackers could eavesdrop on sensitive communications, extract secrets, or compromise applications.

Container Escapes (CVE-2021-25741)

This vulnerability exploited improper handling of symbolic links within Kubernetes. An attacker could use a symlink in a container to escape the container’s isolation and gain access to the host filesystem.

Containers are meant to be isolated from each other and the host. A container escape undermines this foundational security principle and allows attackers to compromise the host machine, potentially affecting other containers and the broader infrastructure. Full access to the host system could enable attackers to escalate privileges, move laterally, and execute arbitrary commands across the cluster.

Etcd Misconfiguration (No CVE)

Etcd is Kubernetes’ key-value store that houses sensitive cluster data, including secrets, configurations, and API access tokens. A frequent misconfiguration is leaving etcd exposed to the public internet without proper authentication.

Etcd is a treasure trove for attackers. Gaining access to it could expose everything needed to compromise a Kubernetes cluster entirely. Unauthorized access could lead to data exfiltration, cluster manipulation, and full compromise of Kubernetes environments.

Supply Chain Vulnerabilities (No CVE)

This category involves vulnerabilities in third-party tools, container images, or Helm charts that integrate with Kubernetes. The SolarWinds attack is a prime example, where attackers inserted malicious code into widely used software that propagated through supply chains.

Kubernetes relies heavily on external tools and pre-built container images. A compromised image or dependency could introduce malware into production environments. Attackers can gain access to Kubernetes workloads, spread malware, or disrupt operations at scale, often without the victim realizing the source of the breach.

Are these CVEs still an issue for organizations? Likely not. All are patched, meaning that updates addressing these specific vulnerabilities are available. But applying the necessary patches is still an issue. Further, new vulnerabilities often emerge using similar patterns of weakness, attack vectors, and security missteps. 

So what can you do?

How Kubernetes Exploits Are Detected and Stopped

Kubernetes compromises typically follow a recognizable chain after initial access. Each stage leaves signals that defenders can watch for, and controls at each stage can break the chain.

Initial access

An attacker gains a foothold through an application or a Kubernetes entry point. Watch API server audit logs for unusual API use, unexpected interactive kubectl exec-style access, abnormal requests to node proxy or log endpoints, and anomalous service account use. Least-privilege RBAC, application hardening, and restricting sensitive Kubernetes features all shrink this entry point.

Privilege escalation

Attackers push a compromised workload toward higher privilege through privileged containers, allowPrivilegeEscalation: true, dangerous capabilities like SYS_ADMIN, or host namespace sharing. Monitor for:

• Suspicious execs
• API changes that introduce privileged settings or new capabilities
• Unusual node-level processes
• Unexpected SYSTEM-level activity on Windows nodes

Several controls limit escalation. Use Pod Security Admission and admission policies that block privileged pods and host namespaces, and keep Kubernetes patched. Drop capabilities by default, and set runAsNonRoot: true and allowPrivilegeEscalation: false.

Lateral movement

With more privilege, the attacker tries to reach other pods, namespaces, and nodes. Look for unexpected pod-to-pod or east-west traffic, unusual namespace access in audit logs, attempts to enumerate secrets or workloads, and access to service account token paths. Network policies, segmentation, tightly scoped service accounts, and minimal host networking keep a single compromise contained.

Persistence

The attacker tries to keep access by creating or modifying deployments, controllers, and other long-lived resources, or by changing the host. Watch for new or changed workloads, configuration drift from approved baselines, and repeated abnormal access from the same identity or node. Admission policies, continuous compliance checks, image verification, and tight control over who can modify workloads make persistence harder.

Data access

Finally, the attacker goes after secrets, configuration, and other sensitive data. Monitor for unusual secret access and unexpected egress. Secret management, RBAC that limits access to secrets, and network policies that restrict egress reduce what can be taken and where it can go.

If exploitation is suspected, a short checklist keeps the response focused:

• Contain: Isolate affected nodes or workloads, stop suspicious interactive sessions, and restrict access to sensitive Kubernetes features if feasible.
• Scope: Review API server audit logs, identify unusual service account use, and determine which nodes, namespaces, and workloads were touched.
• Investigate: Check for suspicious execs, new processes or scheduled tasks, pod spec changes, unusual egress, and secret access.
• Eradicate: Patch Kubernetes to a fixed version, remove unauthorized changes, and rotate exposed credentials and secrets.
• Recover: Restore affected nodes and workloads from trusted sources, and re-enable access only after patching, monitoring, and policy controls are in place.

Essential Kubernetes Vulnerability Lessons

By analyzing these vulnerabilities and taking proactive steps, organizations can significantly reduce their Kubernetes attack surface. Here are some actionable takeaways from each of the key vulnerabilities highlighted.

API Server Exploits (CVE-2019-11247)

Lessons learned:

• Misconfigured Role-Based Access Control (RBAC) can allow privilege escalation, granting attackers unauthorized access to cluster resources.
• Overly permissive access is a recurring issue in Kubernetes environments.

Steps to take next:

• Audit RBAC policies to ensure least-privilege access.
• Validate RBAC configurations.
• Regularly review and rotate Kubernetes service account tokens.

Pod Security Bypass (CVE-2020-8554)

Lessons learned:

• Misconfigured network policies can allow attackers to manipulate ExternalIP services, enabling traffic interception or man-in-the-middle (MITM) attacks.
• Strong network isolation is critical to securing Kubernetes clusters.

Steps to take next:

• Implement strict ingress/egress policies.
• Apply default-deny network policies, then explicitly allow only the connections each workload needs. Use network visibility to confirm traffic matches those rules.
• Regularly test network configurations against benchmarks.

Container Escapes (CVE-2021-25741)

Lessons learned:

• Improper handling of Kubernetes volume mounts can allow attackers to bypass container isolation, compromising the host filesystem.
• Runtime security is crucial to detect and prevent container escapes.

Steps to take next:

• Upgrade Kubernetes to the latest version to patch known vulnerabilities.
• Enforce Pod Security Standards with Pod Security Admission, built into Kubernetes since version 1.25, by applying the predefined Baseline or Restricted level through namespace labels. Custom rules, such as image provenance requirements, need a separate policy engine. Add runtime monitoring on top to detect anomalies.
• Use sandboxed runtimes for high-security workloads.

Etcd Misconfiguration

Lessons learned:

• Leaving etcd exposed without authentication or encryption can grant attackers access to sensitive cluster data, including secrets and configurations.
• Etcd security is foundational to overall Kubernetes cluster security.

Steps to take next:

• Enable etcd encryption for sensitive data at rest.
• Restrict etcd access to the Kubernetes control plane using firewalls or private networks.
• Regularly monitor etcd logs for unauthorized access attempts.

Supply Chain Vulnerabilities

Lessons learned:

• Compromised container images or Helm charts can introduce malicious code into Kubernetes environments.
• Trusting unverified third-party tools or dependencies poses significant risks.

Steps to take next:

• Use trusted image registries and verify container images with image signing tools.
• Utilize Software Bills of Materials (SBOMs) to track dependencies and identify vulnerabilities.
• Regularly scan container images.

How to Scan Kubernetes for Vulnerabilities

Scanning shows up in almost every set of remediation steps above, but “scanner” covers several very different tools. Each category sees a different slice of a Kubernetes environment.

Trivy is a familiar example of an image scanner, though it also checks for IaC misconfigurations, Kubernetes security risks, and more. It’s useful for checking a container image for vulnerabilities before deployment and is strong on image and package risk. On its own, though, it isn’t a full Kubernetes security solution.

No single scanner covers images, manifests, RBAC, network exposure, node drift, and runtime behavior equally well. The practical answer is to combine scanner types in a sequence that moves from build artifacts to the live cluster:

• Scan container images. Run scans during the build process and again in the registry, since some issues only show up after build time. Automate this so every image is checked consistently.
• Scan Helm charts and manifests. Review Kubernetes YAML and Helm charts for risky configurations before deployment. Where possible, use admission controls or webhooks to block unsafe workloads.
• Check cluster configuration against benchmarks. Audit the cluster against hardening benchmarks such as KCCSS to catch unsafe defaults and misconfigurations that make other vulnerabilities worse.
• Validate live runtime findings. Scan running workloads after deployment to confirm whether an issue is actually present and exploitable, given real permissions, exposure, and network paths.

When reviewing results, focus on critical CVEs, reachable packages, internet exposure, privileged pods, weak RBAC, exposed secrets, and risky network paths. Then follow a basic remediation loop:

• Verify the finding.
• Prioritize by exploitability and exposure.
• Fix the issue.
• Redeploy.
• Rescan to confirm it’s resolved.

Run scanning continuously in CI/CD, and again after cluster upgrades or major configuration changes, so new risks are caught quickly.

Kubernetes API Deprecations That Affect Security Controls

Kubernetes deprecates and removes old API versions as it evolves. Manifests that use a removed version stop working once a cluster is upgraded past the removal release, and that includes manifests that define security controls.

The clearest example is PodSecurityPolicy. PodSecurityPolicy using policy/v1beta1 was deprecated in Kubernetes 1.21 and removed in 1.25, so teams still relying on it should migrate to Pod Security Standards.

Steps to take next:

• Check clusters and manifests for deprecated APIs before every upgrade.
• Migrate deprecated resources to supported API versions, using tools like kubectl-convert to convert manifests.

Protect Kubernetes in Real-Time with Upwind

Upwind includes cloud baseline monitoring designed to track potential issues in Kubernetes implementations, bringing together the context of your environment, dependencies, criticality, and real-time behaviors so truly critical Kubernetes vulnerabilities are identified and addressed faster.

Continuously monitor Kubernetes to prioritize risk, detect and respond to threats, and monitor real-time activity. It all works together to ensures that security teams have the information they need to track potentially malicious behavior. 

For more information on Upwind’s vulnerability management for Kubernetes, schedule a demo.

Frequently Asked Questions