PwnEscape permaneció oculto en la pila de red del núcleo durante 18 años

La versión resumida

En qué consiste: CVE-2026-99999, que el investigador denomina «PwnEscape», es una vulnerabilidad relacionada con la forma en que el núcleo de Linux calcula las sumas de comprobación IPv4 de los paquetes que llegan con metadatos de descarga adjuntos. Una máquina virtual invitada puede proporcionar metadatos de descarga de sumas de comprobación que hagan que el host escriba dos bytes en una cabecera IPv4 que el núcleo ya haya validado. El CNA del núcleo lo publicó el 15 de octubre de 2026.

Repercusión: La memoria del host se filtra en los paquetes que envía el invitado, y Vercel afirma que esa parte se demostró en sus entornos de pruebas de producción. El investigador también provocó fallos en los hosts y ejecutó código en ellos con privilegios de root, pero solo en sus propias máquinas KVM y Firecracker, configuradas para emular el entorno de Vercel.

Gravedad: El CNA del núcleo le otorga una puntuación de 9,3 (crítica) según el CVSS 3.1, con un vector de ataque local y un ámbito modificado. Sin embargo, en un servidor multitenant, «local» puede referirse a una máquina virtual alquilada por uno de tus clientes, y el daño recae sobre el servidor subyacente.

Quiénes se ven afectados: El código vulnerable se remonta a la versión 2.6.27 de Linux, de 2008. Se prevé que se vean afectados los núcleos de Enterprise Linux desde la versión EL7 hasta la EL10, incluidos RHEL, AlmaLinux, Rocky Linux, Oracle Linux y CloudLinux, aunque aún no se han verificado los árboles de código fuente de cada núcleo. Los hosts que ejecutan máquinas virtuales sobre las que no tienen control son los primeros en verse afectados, junto con los servidores compartidos en los que usuarios no de confianza disponen de un shell. En las versiones de EL8 a EL10, /dev/kvm es escribible por todos de forma predeterminada, por lo que esos usuarios podrían arrancar su propia máquina virtual y atacar el host desde ella.

Estado: La corrección se incorporó al código principal el 14 de octubre, y siete núcleos estables de origen la incluyeron el 15 de octubre. A fecha de 16 de octubre, ningún núcleo de distribución había incorporado la corrección. No existe ningún código de explotación público ni se ha informado de ningún caso de explotación en el mundo real. Se trata de una divulgación coordinada, no de una vulnerabilidad «zero-day».

Haz lo siguiente ahora mismo: en los hosts que ejecutan máquinas invitadas no fiables, desactiva la descarga de sumas de comprobación en las interfaces «virtio-net» de dichas máquinas invitadas y acepta la pérdida de rendimiento. Esa configuración no afecta a las máquinas virtuales que un usuario local inicie para sí mismo, por lo que, en los hosts con usuarios de shell no fiables, desactiva también los espacios de nombres de usuario sin privilegios. Si compilas tus propios núcleos, cambia a una versión estable fija del código fuente original.

En un host de libvirt, comprueba la definición de un sistema invitado para ver si hay ajustes explícitos de suma de comprobación:

virsh dumpxml <domain> | grep ‘csum=’

Esos atributos solo aparecen en el XML cuando alguien los ha configurado. En el caso de una interfaz virtio, una salida vacía significa que se aplican los valores predeterminados de QEMU, y dichos valores predeterminados mantienen activada la descarga de la suma de comprobación.

La versión larga

El alojamiento de máquinas virtuales multitenant se basa en una promesa: todo lo que un cliente ejecute dentro de su máquina virtual invitada permanece dentro de ella. PwnEscape rompe esa promesa con una escritura de dos bytes que el núcleo del host realiza sobre sí mismo.

Lo que hace que este fallo sea inusual es el lugar donde se encuentra. No está en KVM y, a diferencia de Januscape y Zapscape a principios de este año, no requiere virtualización anidada. El fallo se encuentra en la ruta de salida IPv4 habitual del host. Una máquina invitada llega hasta allí de la misma forma que lo hace miles de veces por segundo: solicitando al host que complete una suma de comprobación por ella.

La corrección se encuentra en el código fuente original y los núcleos de las distribuciones aún no la han incorporado, aunque ya se ha publicado un informe detallado junto con el CVE. Hasta que ambos se sincronicen, los servidores siguen estando expuestos.

Lo que realmente ha pasado esta semana

Paulos Yibelo, de pwn.ai, descubrió el fallo durante la tercera jornada del desafío «Vercel Sandbox $1M». El 4 de septiembre comunicó la causa principal de forma privada a los responsables de seguridad del núcleo y a los encargados del mantenimiento de la red, y Michael S. Tsirkin, de Red Hat, lo reprodujo tres días después.

La serie de parches se publicó en netdev el 19 de septiembre. La corrección más específica de Tsirkin, el commit 6785011f8b16, se aplicó al árbol de redes el 8 de octubre y se incorporó a la rama principal el 14 de octubre, el mismo día en que Vercel publicó los resultados de su desafío. El CVE, siete kernels estables y el informe del investigador, «PwnEscape: Guest-to-Host KVM Escape», se publicaron el 15 de octubre. El informe explica el fallo en detalle, pero no incluye ningún código de explotación.

Cómo dos bytes provocan una fuga de memoria en el servidor

Los paquetes que llegan a través de TAP, vhost-net o AF_PACKET pueden incluir un «virtio_net_hdr», un pequeño bloque de indicaciones de descarga proporcionadas por el remitente. Dos de esas indicaciones, «csum_start» y «csum_offset», indican al núcleo dónde comienza la región de la suma de comprobación y dónde debe almacenarse el resultado, y el paquete se marca como «CHECKSUM_PARTIAL» para que algún componente posterior termine el proceso.

El punto débil es la comprobación de entrada. La función `virtio_net_hdr_to_skb()` solo comprueba que `csum_start` se encuentre, como mínimo, a 20 bytes dentro del búfer. En TAP, ese búfer comienza con la cabecera de Ethernet de 14 bytes, por lo que 20 bytes se sitúan justo dentro de la cabecera IPv4. No hay ninguna comprobación que compare `csum_start` con el final de la cabecera IP.

Cuando el host tiene que fragmentar el paquete, ip_do_fragment() llama a skb_checksum_help(), que calcula la suma de comprobación y escribe dos bytes en csum_start + csum_offset. El invitado proporciona los datos a los que se aplica la suma de comprobación, por lo que, en la práctica, controla esos dos bytes. La escritura nunca sale del búfer del paquete. Se inserta en una cabecera IP que el núcleo ya ha analizado, enrutado y considerado fiable.

A continuación, el fragmentador vuelve a leer esa cabecera. En el caso del investigador, el primer byte pasó de 0x45 a 0x4f, lo que seguía siendo IPv4, pero el campo de longitud de la cabecera (ihl) indicaba ahora 60 bytes en lugar de 20. La función `ip_frag_next()` copia ese número de bytes de la cabecera en cada fragmento. Los datos lineales válidos del paquete eran solo 28 bytes —20 de cabecera y 8 de carga útil—, por lo que los últimos 32 bytes de cada copia procedían de la memoria del host más allá del final del paquete. Estos salen del host como opciones IPv4 en los fragmentos transmitidos, donde cualquier receptor controlado por el atacante puede leerlos.

Treinta y dos bytes no es mucho, pero la fuga se repite mientras el invitado siga enviando datos. El investigador lo combinó con una técnica de «heap grooming» para introducir escrituras seleccionadas de 64 bytes en la memoria del núcleo del host y, a continuación, ejecutó un programa auxiliar en el host con privilegios de root, en cuatro arranques en frío distintos en el laboratorio. Esa cadena de ejecución no es pública, y TuxCare no ha reproducido nada de ello.

Cómo interpretar la puntuación de 9,3

El vector es AV:L/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H, y la parte AV:L es la que suele confundir a la gente.

Lo que importa es el cambio en el alcance. El atacante se encuentra en un dominio de seguridad, el invitado, y el daño se produce en otro, el anfitrión. Esa es precisamente la situación que el alcance del CVSS pretende expresar, y es la razón por la que un fallo local obtiene una puntuación de 9,3. El NVD aún no había publicado su propio análisis en el momento de redactar este artículo, por lo que la puntuación del CNA es la única disponible.

Al menos una base de datos de vulnerabilidades ya la incluye como explotable de forma remota. Por sí sola, no lo es. CHECKSUM_PARTIAL y csum_start son metadatos del búfer de paquetes del núcleo, no bytes del paquete. Las tarjetas de red nunca los establecen a partir de los datos recibidos. GRO puede establecerlos, pero solo a partir de una cabecera TCP que el propio núcleo haya analizado, y solo para paquetes IPv4 sin opciones IP. Un paquete manipulado procedente de Internet no puede llegar hasta allí.

Un atacante remoto necesita primero un punto de acceso, ya sea en una máquina virtual, un contenedor o una cuenta local. En un servidor de máquinas virtuales multitenant, ese punto de acceso cuesta una tarjeta de crédito.

¿Quién puede llegar al bicho?

El escenario principal consiste en una máquina virtual invitada no fiable que accede al host a través de TAP o vhost-net, tal y como se ha demostrado tanto en configuraciones de KVM como de Firecracker. La máquina invitada no necesita acceder a los dispositivos del host, ya que el VMM ya dispone del descriptor de archivo TAP y transmite los metadatos de descarga sin modificarlos.

Las vías locales son menos evidentes. Dentro de un espacio de nombres de usuario, un proceso sin privilegios podría abrir tun con IFF_VNET_HDR, ya que tun comprueba CAP_NET_ADMIN únicamente dentro de ese espacio de nombres, donde el proceso lo posee. AF_PACKET con PACKET_VNET_HDR es un caso similar, ya que necesita CAP_NET_RAW, que un espacio de nombres de usuario también concede. Ninguno de los dos casos se ha reproducido. Los espacios de nombres de usuario sin privilegios, habilitados por defecto en EL8 y versiones posteriores, son el principal factor de vulnerabilidad en este caso, pero no el único. El acceso a un dispositivo macvtap o ipvtap ya existente es una vía independiente con sus propios requisitos de permisos. Lo mismo ocurre con una máquina virtual que el usuario arranca por su cuenta. En las versiones desde EL8 hasta EL10, las reglas predeterminadas de udev permiten que /dev/kvm sea escribible por todos, por lo que cualquier usuario local puede iniciar una máquina virtual y tener privilegios de root en su interior. Si esa máquina virtual obtiene un backend TAP o vhost-net, normalmente a través de un espacio de nombres de usuario, puede enviar al host los mismos metadatos de descarga manipulados que lo haría un invitado de un cliente. Los servidores de alojamiento compartido entran en el ámbito de esta vulnerabilidad, incluso si nunca ejecutan una máquina virtual de un cliente.

Por ese motivo, merece la pena echar un vistazo a los ejecutores de CI compartidos que compilan el código de los clientes en contenedores sin privilegios, aunque la ruta local aún deba someterse a pruebas.

En primer lugar, se tratan los servidores host que ejecutan máquinas virtuales sobre las que no tienes control y los servidores compartidos que proporcionan un shell a usuarios no fiables; a continuación, los demás sistemas que ejecutan código no fiable. El resto presenta un nivel de exposición conocido menor y debería recibir la corrección a través de las actualizaciones de seguridad habituales, en función de su riesgo real.

¿Es PwnEscape una vulnerabilidad de día cero?

En la publicación de Vercel se lo denomina «vulnerabilidad de día cero del núcleo de Linux», y cuando Yibelo la descubrió en agosto, nadie en la comunidad de desarrollo principal sabía de su existencia. Sin embargo, cuando se publicó el CVE-2026-99999, la corrección ya se había incorporado a la rama principal. Para quienes se pronuncien ahora, se trata de una divulgación coordinada con una corrección disponible, sin código de explotación público y sin que se haya informado de ningún uso fuera del ámbito de la investigación autorizada.

El investigador prevé que en unas semanas aparecerán exploits que afecten a las configuraciones más vulnerables de los hipervisores, y que en menos de un mes lo hagan contra las configuraciones predeterminadas de los hipervisores. Tómalo como una previsión del investigador. Los servidores expuestos no deberían esperar a ver si se cumple.

¿A quién afecta?

Estado del kernel del proveedor a fecha de 16 de octubre de 2026, independiente del estado de los parches sin reinicio de KernelCare:

No te fíes del estado de la distribución que muestra el comando «uname -r». Los núcleos empresariales incorporan correcciones sin cambiar su versión base, por lo que un núcleo EL que parezca anterior a la 5.10.272 no prueba nada en ningún sentido. Solo un aviso del proveedor o un parche verificado que no requiera reinicio para ese núcleo concreto puede zanjar la cuestión.

Consigue KernelCare hoy mismo →

Desactivar los requisitos previos hasta que se publique una solución

Cada una de las opciones que figuran a continuación elimina un requisito previo. TuxCare aún no ha probado ninguna de ellas, así que pruébalas primero en un sistema invitado no crítico.

Lo importante para los hosts de máquinas virtuales es no ofrecer la descarga de la suma de comprobación a los invitados en los que no confíes. Si utilizas QEMU directamente, configúralo en el dispositivo:

-dispositivo virtio-net-pci, netdev=n0, csum=off, guest_csum=off

With libvirt, add <driver><host csum=’off’/><guest csum=’off’/></driver> inside the guest’s <interface> element. Either way it’s per VM, needs a full guest restart, and costs throughput because the guest loses TSO and GSO. Firecracker is the awkward case. It was one of the demonstrated targets, and whether offload can be switched off per VM there hasn’t been verified yet.

Solo para la ruta local, desactiva los espacios de nombres de usuario sin privilegios. Anota primero el valor actual con `sysctl user.max_user_namespaces` y, a continuación, ejecuta:

sysctl -w user.max_user_namespaces=0

Esto bloquea los nuevos espacios de nombres de usuario, pero no afecta a los ya existentes. Para que el cambio sea permanente, guarda la configuración en un archivo dentro de /etc/sysctl.d/; para revertirlo, elimina ese archivo y vuelve a establecer el valor anterior. Esta opción tiene un coste real: impide el funcionamiento de los contenedores sin privilegios de root y de los entornos aislados de Chrome y Flatpak, y no tiene ningún efecto sobre la vía de escape del sistema invitado. Si solo las cuentas de confianza deben ejecutar máquinas virtuales, una regla de udev que establezca /dev/kvm en 0660 para el grupo kvm también bloquea la ruta propia de la máquina virtual, aunque no la ruta directa de tun.

Aplicar parches y verificar el núcleo en ejecución

Si compilas tus propios núcleos, cambia a una de las versiones estables corregidas que aparecen en la tabla. La instalación de una de ellas no cambia nada hasta que el servidor arranca con ella, así que comprueba cuál es la que se está ejecutando realmente:

uname -r

Un servidor en el que se haya instalado el nuevo núcleo pero que nunca se haya reiniciado sigue ejecutando el núcleo vulnerable, y los hipervisores son los que más problemas causan.

Una vez publicado para tu kernel, el parche sin reinicio de KernelCare puede aplicar la corrección sin necesidad de reiniciar el sistema. Si las actualizaciones automáticas están activadas, el parche se instala en cuanto está disponible en el canal de actualizaciones del kernel en ejecución, y el comando `kcarectl –update` lo solicita cuando sea necesario. Para comprobar la cobertura:

kcarectl –patch-info | grep «CVE-2026-99999»

Los parches que no requieren reinicio ya están en producción para la mayoría de las instancias (consulta el estado más arriba), por lo que, una vez que se haya aplicado el tuyo, el comando debería mostrar el CVE del núcleo en ejecución; hasta que lo haga, mantén activas las medidas de mitigación.

Luego está la corrección. La corrección en el código original es pequeña: se han añadido 44 líneas y se han eliminado 12 en seis archivos. Añade una función auxiliar, ip_check_csum_start(), que rechaza los paquetes cuyo csum_start apunta antes del final de la cabecera IP, y la invoca antes de que se complete la suma de comprobación en cinco puntos: fragmentación IP, fragmentación de conntrack en puentes, nfnetlink_queue, xt_CHECKSUM y salida de xfrm. El mensaje de la confirmación califica el cambio como una medida de «defensa en profundidad» y afirma que «próximamente se implementará una validación más completa en la entrada». Por lo tanto, cabe esperar una segunda corrección en el código fuente y, posiblemente, un segundo parche que no requiera reinicio junto con ella. No cierres el ticket del primero.

Por qué es importante PwnEscape

El límite del sistema invitado abarca mucho más que el hipervisor. Todo el código del host que confía en lo que el sistema invitado indica sobre sus propios paquetes se basa en él. Los metadatos de descarga existen para ganar velocidad y, durante 18 años, el núcleo se ha fiado de lo que el sistema invitado indicaba sobre dónde debía ir una suma de comprobación.

Si ejecutas máquinas virtuales de terceros, desactiva ya mismo la descarga de sumas de comprobación en los invitados no fiables. Si concedes acceso a un shell a otras personas, desactiva los espacios de nombres de usuario sin privilegios. En cualquier caso, aplica el parche al núcleo en ejecución tan pronto como esté disponible para tu versión. A continuación, sigue atento a las actualizaciones del código fuente, ya que se avecinan más medidas de validación de entradas. Cuando reiniciar un hipervisor implique evacuar primero los sistemas invitados, el parche «rebootless» de KernelCare está diseñado para corregir el fallo en el núcleo en ejecución una vez que esté disponible para tu versión, sin necesidad de evacuación ni de una ventana de mantenimiento.

Consigue KernelCare hoy mismo →

Cronología

Referencias

Las fuentes principales de esta entrada son el registro CVE-2026-99999 publicado por la CNA del kernel el 15 de octubre de 2026, los hallazgos de Vercel sobre el desafío «$1M Vercel Sandbox» (14 de octubre de 2026) y el informe del investigador «PwnEscape: «Guest-to-Host KVM Escape» (15 de octubre de 2026), el informe de parche del investigador en netdev, la corrección del proyecto original 6785011f8b16, el aviso de LWN sobre las siete versiones estables y la entrada en el sistema de seguimiento de seguridad de Debian.