CVE-2026-99999, conocida como PwnEscape, es una vulnerabilidad del kernel Linux que puede romper el aislamiento entre una máquina virtual y su servidor anfitrión. Si tienes un VPS, la pregunta urgente para tu proveedor es si el host ya ejecuta un kernel corregido. Actualizar Linux dentro de tu VPS no actualiza ese servidor físico.
Revisión de fuentes: 17 de octubre de 2026. El registro del CVE se publicó el 15 de octubre. Esta guía distingue capacidad técnica, demostraciones documentadas y recomendaciones operativas; no es una prueba de explotación ni una auditoría de servidores. Registro de CVE-2026-99999 en NVD.
Qué es PwnEscape y por qué importa para un VPS
El fallo está en el procesamiento IPv4 del kernel Linux: ciertos metadatos de checksum —la información utilizada para comprobar paquetes de red— no se validan correctamente. Esto permite corromper datos durante su procesamiento. No es un fallo de una web o de su contraseña: está en una capa del sistema que procesa tráfico de las máquinas virtuales. La corrección añade una validación antes de completar el checksum. Corrección incorporada al kernel Linux.
En una configuración vulnerable, alguien que controla una máquina virtual puede intentar alcanzar el host que la ejecuta. El problema no reside en KVM propiamente dicho, sino en la pila de red de Linux que interviene en ese entorno. El investigador Paulos Yibelo documentó la fuga de memoria y una posterior escalada hasta escapar al host en sus propios equipos. Publicación técnica de PwnEscape reproducida en oss-security.
Si esos términos son nuevos para ti, nuestra explicación de qué es un VPS y cómo funciona ayuda a distinguir tu servidor virtual del equipo físico compartido.
Qué podría hacer un atacante
Red Hat describe tres consecuencias posibles: exposición de memoria, caída del sistema y ejecución de código en el host. Su evaluación CVSS es 8.8, mientras que la del registro CVE es 9.3; difieren, entre otras cosas, en los privilegios requeridos. Ambas consideran un vector local: no significa que el atacante tenga que estar físicamente en el centro de datos. Evaluación y alcance de Red Hat.

Ilustración generada con IA, no captura de un incidente. 1: máquina virtual controlada por un atacante. 2: límite de aislamiento vulnerable. 3: host Linux. Representa un escenario posible, no que todas las máquinas alojadas hayan sido comprometidas.
Ejemplo hipotético: si un host alojara 20 VPS y un ataque consiguiera detenerlo, los servicios de esos 20 VPS podrían quedar interrumpidos. No es una cifra de víctimas de PwnEscape: explica por qué un fallo en una capa compartida puede afectar también a clientes que no ejecutaron nada malicioso.
Alcance real: qué se ha demostrado y qué no
Vercel confirmó una fuga de memoria del host en sandboxes de producción. La caída del host y la ejecución de código con privilegios de administrador se demostraron en máquinas KVM y Firecracker del investigador que reproducían su configuración. Vercel indicó que ningún reporte mostró lectura de archivos, secretos o datos de aplicaciones de clientes. Eso no equivale a afirmar que cualquier fuga sea inocua. Informe de Vercel del 14 de octubre.
No disponemos de un recuento global verificable de servidores comprometidos. Las fuentes revisadas no permiten convertir el número de instalaciones Linux, reportes de un programa de recompensas o años de antigüedad del código en víctimas reales. Tampoco permiten asegurar que todos los proveedores sean explotables de la misma manera.
| Tu situación | Qué significa y qué revisar |
|---|---|
| VPS sobre un host Linux vulnerable | Prioridad para el proveedor: corregir el kernel del host y verificar que la corrección está activa. |
| Servidor dedicado Linux con usuarios o cargas no confiables | No descartes el riesgo solo porque no ofreces VPS. Revisa el aviso aplicable a tu distribución y configuración. |
| Windows dentro de una VM alojada en Linux | No es un CVE del kernel Windows. Aun así, una caída o compromiso del host podría afectar al servicio: importa también el sistema anfitrión. |
| WordPress, una base de datos o un servidor de juegos | No son el componente defectuoso de este CVE. Pueden sufrir consecuencias si falla su infraestructura; actualizar solo la aplicación no corrige el host. |
| Host con una corrección válida ya activa | Se aborda esta vulnerabilidad concreta. No demuestra ausencia de incidentes anteriores ni elimina otros riesgos de seguridad. |
La tabla traduce el fallo de kernel a decisiones de alojamiento; las consecuencias sobre aplicaciones son escenarios de impacto, no incidentes confirmados en esos productos.
Kernel corregido en Debian 12 y Debian 13
El rastreador oficial de Debian identifica estas versiones corregidas del paquete fuente linux. No son cadenas que deban coincidir literalmente con la salida de uname -r.
| Distribución | Versión corregida | Aviso |
|---|---|---|
| Debian 12, Bookworm | 6.1.190-1 | DLA-4841-1 |
| Debian 13, Trixie | 6.12.113-1 | DSA-6568-1 |
Referencia consultada el 17 de octubre: estado de CVE-2026-99999 en Debian. Para kernels de otro proveedor, backports o imágenes personalizadas, exige el aviso específico: una numeración distinta no demuestra por sí sola vulnerabilidad o protección.
Otras distribuciones: AlmaLinux anunció el 16 de octubre kernels corregidos en su repositorio de pruebas para las ramas 8, 9 y 10. No confundas disponibilidad en pruebas con una actualización estable de producción; revisa si su estado cambió. Para Ubuntu o RHEL consulta la versión y variante concretas en su aviso. Estado de AlmaLinux · Estado de Ubuntu.
Comprobación rápida: qué puedes verificar desde tu VPS
Estos comandos de consulta no modifican el sistema. En un Linux con systemd permiten identificar distribución, kernel en ejecución y virtualización detectada. No son un detector de PwnEscape ni de infección.
Elige un VPS con la infraestructura al día
TERAMONT ha actualizado sus nodos Debian 12 y 13 al kernel corregido para este CVE. Consulta nuestros planes y elige los recursos para tu proyecto.


cat /etc/os-release
uname -r
systemd-detect-virt
/etc/os-releaseidentifica el sistema donde ejecutas el comando.uname -rmuestra su kernel activo. Dentro de una VM con kernel propio, no muestra el kernel del host.systemd-detect-virtpuede indicarkvm, otro entorno onone. Si no existe el comando o no detecta virtualización, eso no certifica seguridad.
Conserva esos datos para soporte. Para evaluar el host hacen falta el inventario del proveedor y su aviso de corrección. No ejecutes pruebas de escape en un VPS de producción: pueden interrumpir servicios ajenos y no son necesarias para verificar un parche.
Mensaje para pedir confirmación a tu proveedor
Hola. Necesito confirmar el estado de CVE-2026-99999 (PwnEscape) en el host de mi VPS:
1. ¿Qué paquete o aviso de seguridad corrige el kernel del host?
2. ¿La corrección ya está activa, o falta reiniciar/activar el parche?
3. ¿Cuándo quedó aplicada y cubre también los nodos de migración?
4. ¿Debo realizar alguna acción dentro de mi VPS?
Gracias. No necesito información de otros clientes.
Cómo corregirlo sin confundir instalación con protección
Si administras el host, recomendamos este orden de trabajo. Si solo administras un VPS, coordina la parte del anfitrión con tu proveedor.
- Identifica el kernel y el aviso aplicable. Comprueba distribución, variante y paquete; usa repositorios oficiales o la actualización soportada por tu plataforma.
- Prepara mantenimiento y recuperación. Verifica copias recuperables y acceso a consola. Un reinicio del host puede interrumpir sus VPS; cualquier migración debe terminar en un nodo también corregido.
- Instala la actualización corregida. Revisa qué paquetes propone el gestor antes de aceptarlos. No instales un kernel de pruebas o una release candidate solo porque su número parezca más reciente.
- Activa la corrección. Normalmente implica arrancar el kernel nuevo. Un livepatch solo cuenta si su proveedor confirma cobertura de este CVE y su aplicación efectiva.
- Comprueba el resultado. Verifica el kernel realmente en ejecución, su correspondencia con el aviso y el estado de todos los nodos. Mantén también actualizado el sistema del VPS.
Un firewall, cambiar la contraseña SSH o reiniciar únicamente la VM no sustituyen el parche del host. Red Hat no presenta una mitigación general que cumpla sus criterios de despliegue y estabilidad en el aviso consultado.
¿Cómo saber si ya hubo un ataque?
Estar en una versión vulnerable no significa haber sido comprometido; tener el parche tampoco demuestra que no ocurrió antes. Como respuesta operativa, si detectas reinicios inexplicables, alertas de integridad o actividad anómala, conserva registros y contacta al proveedor para investigar el host. Esas señales no son específicas de PwnEscape. Si se confirma compromiso, aislar, reconstruir desde una base confiable y rotar credenciales debe formar parte de un plan de respuesta, no de una supuesta “limpieza” garantizada.
Estado de TERAMONT y siguiente paso
TERAMONT ha actualizado sus nodos Debian 12 y Debian 13 a versiones del kernel que corrigen CVE-2026-99999, según la confirmación de su dirección recibida el 17 de octubre de 2026. Esta declaración describe la actualización comunicada por TERAMONT; no presentamos este artículo como una auditoría independiente ni como una garantía de riesgo cero.
Si buscas alojamiento, puedes consultar nuestros planes de VPS Hosting de TERAMONT. Para este incidente, el criterio útil al elegir proveedor es concreto: que pueda confirmar el parche del host, su activación y la cobertura de los nodos. La seguridad no termina al contratar; las aplicaciones y credenciales dentro de tu VPS también requieren mantenimiento.







