--- title: "CVE-2021-31440: Kubernetes container escape using eBPF" source: "https://www.tigera.io/blog/cve-2021-31440-kubernetes-container-escape-using-ebpf/" description: "Learn about the CVE-2021-31440 vulnerability, how it works, and mitigation tactics." --- [Technical Blog](https://www.tigera.io/category/technical-blog/) # CVE-2021-31440: Kubernetes container escape using eBPF By [Manoj Ahuje](https://www.tigera.io/blog/author/manoj-ahuje/) on Jun 09, 2021 • 4 min read In a [recent post](https://www.zerodayinitiative.com/blog/2021/5/26/cve-2021-31440-an-incorrect-bounds-calculation-in-the-linux-kernel-ebpf-verifier) by ZDI, researchers found an out-of-bounds access flaw ([CVE-2021-31440](https://nvd.nist.gov/vuln/detail/CVE-2021-31440)) in the Linux kernel’s (5.11.15) implementation of the [eBPF](https://docs.projectcalico.org/about/about-ebpf) code verifier: an incorrect register bounds calculation occurs while checking unsigned 32-bit instructions in an eBPF program. The flaw can be leveraged to escalate privileges and execute arbitrary code in the context of the kernel. This vulnerability allows a local privilege escalation, which means an attacker with non-root access to the system can gain higher privileges by exploiting this vulnerability. The non-root access can be a user account without sudo or group privileges, which are usually provided to the application user. ## Why you should be worried In a Kubernetes environment, containers use the host kernel to run themselves. Therefore, the execution of malicious eBPF code as an unprivileged user in the context of the kernel can result in container escape and privilege escalation to the host. Unprivileged users inside the container need CAP_SYS_ADMIN permission already assigned to the container to run a malicious eBPF program. For Linux kernels 5.8 and above, a new permission, [CAP_BPF](https://kernelnewbies.org/Linux_5.8#Introduce_CAP_BPF_and_CAP_PERFMON_security_capabilities), is added to allow users to run eBPF programs. CAP_BPF is a subset of CAP_SYS_ADMIN. In Kubernetes, [privileged containers](https://kubernetes.io/docs/concepts/policy/pod-security-policy/#privileged) inherit CAP_SYS_ADMIN privileges by default. As a result, unprivileged users inside a privileged container can escalate privileges to the node and break out of the container at the same time, using this vulnerability. ![Screenshot of terminal output showing CAP_SYS_ADMIN capability enabled within a Kubernetes pod, highlighting privilege](https://www.tigera.io/app/uploads/2021/09/eBPF-CVE-1.png)Privileged container with CAP_SYS_ADMIN permission Additionally, the [exploit code](https://github.com/bsauce/kernel-exploit-factory/blob/main/CVE-2021-31440/exp/CVE-2021-31440.c) is generally available on the internet. We expect various malwares targeting Kubernetes will be adding this exploit to escalate privileges after compromise. ## Fix Fixes have been released for Linux kernel versions 5.10.37, 5.11.21, and 5.12.4. It is best practice to upgrade your kernel version when fixes are available for your upstream Linux distribution. In the meantime, you can use the following mitigation approach. ### Mitigation #### **1. Disable unprivileged eBPF execution on nodes** To mitigate this vulnerability, you need to prevent unprivileged users from being able to run eBPF to inject untrusted code. This can be achieved with the following command, which disables unprivileged eBPF execution on Kubernetes nodes. ``` `$ sudo sysctl kernel.unprivileged_bpf_disabled=1` ``` You can confirm changes using the following command, which should have value ‘1’. ``` `$ cat /proc/sys/kernel/unprivileged_bpf_disabled 1` ``` #### **2. Don’t grant CAP_SYS_ADMIN privileges to containers** As we have seen, privileged containers have CAP_SYS_ADMIN privileges by default. If unprivileged eBPF execution is not disabled on the Kubernetes node, unprivileged users from privileged containers can run malicious code to escalate their privileges. #### **3. Don’t grant CAP_BPF permission to containers running on Linux kernel 5.8 and above** If you are using Linux kernel 5.8 and above, you can look for CAP_BPF permission granted to the container in addition to CAP_SYS_ADMIN to remediate this issue on the container front. #### **4. Run application as non-root user** Run your application within a privileged container as [non-root](https://kubernetes.io/docs/tasks/configure-pod-container/security-context/#set-the-security-context-for-a-pod). If the above discussed mitigations are in place, this will ensure that, after a compromise, unprivileged users won’t be able to escalate privileges using this vulnerability. The impact would be limited to the application or service that has been compromised. #### **5. Use zero trust** A zero-trust policy can help limit an attacker’s lateral movement within the Kubernetes cluster if the attacker is not able to escalate privileges after initial compromise due to the above-mentioned mitigations. ## How Calico addresses this vulnerability Calico users using eBPF for higher performance in their Kubernetes clusters are protected from this vulnerability. Calico voluntarily disables unprivileged execution of eBPF code so that regardless of the Linux distribution being used, all customers running eBPF in their Kubernetes clusters are protected.   ***Did you know you can become a certified Calico operator? Learn Kubernetes networking and security fundamentals using Calico in this[free, self-paced certification course](https://link.tigera.io/udqrH).***   [How-To](https://www.tigera.io/tags/how-to/)[Open Source](https://www.tigera.io/tags/open-source/)[Kubernetes Vulnerabilities](https://www.tigera.io/tags/kubernetes-vulnerabilities/) ## Related posts [![Save the Address, Save the Cloud: A Hands-on KubeVirt Live Migration Workshop](https://www.tigera.io/app/uploads/2026/07/Save-the-Address-Save-the-Cloud-A-Hands-on-KubeVirt-Live-Migration-Workshop.png)](https://www.tigera.io/blog/save-the-address-save-the-cloud-a-hands-on-kubevirt-live-migration-workshop/) #### [Save the Address, Save the Cloud: A Hands-on KubeVirt Live Migration Workshop](https://www.tigera.io/blog/save-the-address-save-the-cloud-a-hands-on-kubevirt-live-migration-workshop/) By [Reza Ramezanpour](https://www.tigera.io/blog/author/rezar/) on Jul 9, 2026 In the previous post in this series, we covered why Virtual Machine (VM) Live Migration in Kubernetes is difficult: a VM’s IP is its identity, and the “new” VM on the destination node has to... [Read more](https://www.tigera.io/blog/save-the-address-save-the-cloud-a-hands-on-kubevirt-live-migration-workshop/) [![What’s new in Calico: Spring 2026 Release](https://www.tigera.io/app/uploads/2026/06/Whats-New-in-Calico-NEW-TEMPLATE-2026.png)](https://www.tigera.io/blog/whats-new-in-calico-spring-2026-release/) [Company Blog](https://www.tigera.io/category/company-blog/) #### [What’s new in Calico: Spring 2026 Release](https://www.tigera.io/blog/whats-new-in-calico-spring-2026-release/) By [Veronika Smolik](https://www.tigera.io/blog/author/veronika-smolik/) on Jun 2, 2026 Kubernetes has come a long way since its debut in 2014. It’s gone from running a couple of containerized microservices to orchestrating fleets of production workloads spanning everything from AI agents to full scale VMs... [Read more](https://www.tigera.io/blog/whats-new-in-calico-spring-2026-release/) [![Kubernetes Operational Maturity: Secure and Resilient Cluster Federation with Cluster Mesh](https://www.tigera.io/app/uploads/2026/05/Kubernetes-Operational-Maturity-Secure-and-Resilient-Cluster-Federation-with-Cluster-Mesh.png)](https://www.tigera.io/blog/kubernetes-operational-maturity-secure-and-resilient-cluster-federation-with-cluster-mesh/) #### [Kubernetes Operational Maturity: Secure and Resilient Cluster Federation with Cluster Mesh](https://www.tigera.io/blog/kubernetes-operational-maturity-secure-and-resilient-cluster-federation-with-cluster-mesh/) By [Veronika Smolik](https://www.tigera.io/blog/author/veronika-smolik/) on May 25, 2026 Practically no one runs a single Kubernetes cluster in production these days. Maybe that’s how it started but data sovereignty requirements, acquisitions, AI initiatives and the need for edge servers, among other considerations, have pulled... [Read more](https://www.tigera.io/blog/kubernetes-operational-maturity-secure-and-resilient-cluster-federation-with-cluster-mesh/)