CVE-2026-99999: "PwnEscape" Mitigation

Traducciones al Español
Estamos traduciendo nuestros guías y tutoriales al Español. Es posible que usted esté viendo una traducción generada automáticamente. Estamos trabajando con traductores profesionales para verificar las traducciones de nuestro sitio web. Este proyecto es un trabajo en curso.

CVE-2026-99999 (termed “PwnEscape”) is a Linux kernel vulnerability that was publicly disclosed on October 15, 2026. The vulnerability enables breaking out of virtual machines and containers through sending a raw network packet on a vnet network device. All common Linux distributions since 2008 are believed to be affected.

While Akamai has patched its hypervisors for the known attack path, guest kernels may also be vulnerable under certain circumstances, such as through a less-privileged container or nested virtualization.

It is important to stress that this vulnerability cannot be exploited remotely by itself, since the attacker requires privileged access to a virtual machine or container running on the vulnerable system. Patching or mitigating the exploit path is nevertheless strongly recommended on all affected systems so as to ensure that no unauthorized or even unexpected remote access in, e.g., an automated environment could be elevated in combination with this local privilege escalation into a remote root vulnerability. This is particularly worth stressing in light of several other, unrelated Remote Code Execution (RCE) vulnerabilities discovered in other popular software components, such as the “php2shell” (CVE-2026-109618 and CVE-2026-109619) or “brotli” (CVE-2026-111497) vulnerabilities.

Mitigations

Patches to address the vulnerability have been released by upstream vendors of major Linux distributions. If your distribution has no upstream release available, you may wish to apply a Linux kernel containing the upstream patch.

For container environments (such as Docker), removing the CAP_NET_RAW capability from untrusted workloads will help mitigate at least some of the known vulnerability vectors.

Akamai Cloud (Linode)

Per our Shared Security Model, customers are responsible for making sure their service’s installed applications and code are securely configured and patched. Given the nature of this vulnerability, it should be assumed that all virtual machines running Linux are at-risk for privilege escalation within the VM until patched. (Note: Akamai has taken care of patching our hypervisor which prevents workloads from breaking out of the VM, as part of our responsibility.)

As a local privilege escalation, this vulnerability is not exploitable remotely by itself. Therefore, it is most urgent to fix in multi-tenant/multi-user workloads, or workloads where you allow external code to be executed as a non-privileged user with CAP_NET_RAW and/or CAP_NET_ADMIN capability permissions, including in a container environment. Nested virtualization (running a VM inside of your Linode VM) is another environment where fixing is urgently recommended, although nested virtualization is not a generally available feature. The specifics of your risk exposure will depend highly on your environment, workload, and applications.

Depending on which environment your applications are running in, you have a number of options.

For virtual machines (Linode VMs) you can:

  • Upgrade the OS in your VM to vendor supplied patches following instructions from the OS vendor.
  • Install new Linode VMs using our updated base images containing the upstream fixes. At this time we have provided upgraded/patched images from upstream providers for:
    • AlmaLinux 10, 9, and 8
    • ArchLinux
    • CentOS Stream 9
    • Debian 13 and 12
    • Fedora 43
    • OpenSUSE Leap 15.6
    • Rocky Linux 9 and 8
    • Slackware 15.0
  • We will continue to update the OS versions as upstream providers issue new releases.
  • Older versions of the different Linux distributions remain available for customers to launch. The reason for this is that we cannot assess for our customers what risks they are willing to accept, and that we cannot break automated deployment pipelines for them. We strongly recommend that customers who continue to deploy older releases manually mitigate the vulnerability as described above.
  • If you are using “GRUB 2” (default since August 2018), your Linode will boot with the kernel in the OS disk image. However, if you are still using one of our kernels to boot, the latest kernel configuration (version 7.2.11 as of 2026-10-29) contains the patch for the vulnerability. Older Linode provided kernel configurations (e.g., 6.15.7-x86_64-linode169) remain vulnerable. Customers using these configurations are strongly encouraged to switch to the latest kernel and reboot, or use “GRUB 2” to boot from their own kernel on their primary disk, which has been Linode’s default boot option since 2018.

For Linode Kubernetes Engine (LKE and LKE-E), the underlying nodes run a Linux kernel based on the Debian 13 (for LKE) and Ubuntu 24 (for LKE-Enterprise) distribution. Debian systems have been updated, but as of 2026-10-29, Canonical has not yet provided an OS update; we will apply the update as soon as it becomes available, and existing deployments will need patching as well. You can choose one of the following options:

More Information

You may wish to consult the following resources for additional information on this topic. While these are provided in the hope that they will be useful, please note that we cannot vouch for the accuracy or timeliness of externally hosted materials.

This page was originally published on


Your Feedback Is Important

Let us know if this guide was helpful to you.


Join the conversation.
Read other comments or post your own below. Comments must be respectful, constructive, and relevant to the topic of the guide. Do not post external links or advertisements. Before posting, consider if your comment would be better addressed by contacting our Support team or asking on our Community Site.
The Disqus commenting system for Linode Docs requires the acceptance of Functional Cookies, which allow us to analyze site usage so we can measure and improve performance. To view and create comments for this article, please update your Cookie Preferences on this website and refresh this web page. Please note: You must have JavaScript enabled in your browser.