Product docs and API reference are now on Akamai TechDocs.
Search product docs.
Search for “” in product docs.
Search API reference.
Search for “” in API reference.
Search Results
 results matching 
 results
No Results
Filters
CVE-2026-99999: "PwnEscape" Mitigation
Traducciones al EspañolEstamos 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:
- Upgrade to the latest images by recycling your node pools.
- Manually upgrade to a patched kernel version on your nodes
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