Dos fallos, dos responsables
PwnEscape lleva el identificador CVE-2026-99999. El defecto está en la pila de red IPv4 del kernel, en la función skb_checksum_help, y se alcanza con el tráfico que una máquina virtual envía por virtio-net. La puntuación CVSS 3.1 es 9.3, con vector local (AV:L). Paulos Yibelo (Pwn.ai) lo descubrió durante el desafío Vercel Sandbox y demostró un escape en laboratorio sobre KVM y Firecracker. El kernel expuesto es el del host de virtualización, no el de su VPS.
Vghost lleva el identificador CVE-2026-74580. Afecta al subsistema vhost: una caché de metadatos de las colas virtio (los vrings) no se vacía cuando cambia su configuración, lo que elude una validación de rangos. Un usuario local que pueda abrir /dev/vhost-net o /dev/vhost-vsock puede obtener permisos de root. Hay una prueba de concepto pública. Para ambos fallos, no se informaba de explotación activa al redactar esta guía.
Quién corrige qué
Desplace la tabla
| Caso | Dónde está el defecto | Quién actúa |
|---|---|---|
| PwnEscape (CVE-2026-99999) | Kernel del host de virtualización, pila de red IPv4 | El proveedor, en sus hosts. Nada se corrige desde su VPS |
| Vghost (CVE-2026-74580), lado VPS | Kernel de su VPS, si los nodos `/dev/vhost-*` son alcanzables | Usted: kernel corregido y reinicio |
| Vghost, vía desencadenada desde un invitado | Kernel y QEMU del host, bajo condiciones precisas | El proveedor |
| Actualizar el kernel invitado frente a PwnEscape | El defecto está en el host | Sin protección por este lado; sigue siendo útil para Vghost y otras correcciones |
| Servidor dedicado o VPS donde usted es el hipervisor (KVM, Proxmox) | Usted es el host | Usted: ambos fallos le afectan |
| Contenedores Docker en el VPS | Comparten el kernel del VPS | Corregir el kernel del VPS; reconstruir una imagen no cambia nada |
| Hosting compartido cPanel | Kernel gestionado por el proveedor | El proveedor |
PwnEscape: lo que corresponde al proveedor
Para un escape, hay que corregir el kernel que recibe el tráfico de la máquina virtual, es decir, el del host. Las ramas estables corregidas son 5.10.272, 5.15.223, 6.1.190, 6.6.159, 6.12.113, 6.18.57 y 7.2.11; los kernels de distribución suelen retroportar la corrección sin cambiar el número base, así que lea el boletín de la distribución en lugar de comparar números. El registro CVE muestra además límites de versión poco coherentes: fíese de los trackers de las distribuciones.
En un VPS no puede aplicar esta corrección, y actualizar su kernel invitado no le protege de ella. Pregunte a su proveedor, sea cual sea, si sus hosts están corregidos, en qué fecha y si se prevé reiniciar el host. Aquí no afirmamos que una oferta concreta sea o no vulnerable: solo cuenta la confirmación del operador. En su artículo, el investigador prevé exploits públicos para las configuraciones más débiles en cuestión de semanas: es su previsión, no una constatación, y la evaluación de CISA no señala explotación hasta ahora.
Vghost: lo que le corresponde a usted
Vghost es una escalada local: el atacante ya debe ejecutar código en la máquina, por ejemplo a través de un sitio de cliente comprometido que corre con una cuenta sin privilegios. La corrección del kernel principal es el commit de845981da67. Las primeras versiones estables corregidas son 5.10.265, 5.15.216, 6.1.183, 6.6.152, 6.12.104, 6.18.45, 7.1.9 y 7.2. De nuevo, un kernel de distribución puede llevar la corrección con otro número: compare con el boletín de la distribución, no con el número upstream.
Todo depende de los permisos de los nodos vhost. Según el anuncio de oss-security, en las pruebas de su autor, Ubuntu limitaba /dev/vhost-vsock al grupo kvm, mientras que RHEL, Amazon Linux, Azure Linux y Oracle Linux lo abrían a cualquier usuario. En un VPS que no aloja ninguna máquina virtual, estos nodos normalmente no existen; compruébelo, no lo suponga. La corrección solo surte efecto tras reiniciar con el nuevo kernel.
Comprobar el kernel y la exposición en diez minutos
Leer el kernel en ejecución
uname -r
Este comando muestra el kernel cargado en memoria, no el instalado en disco. Es el número que cuenta para Vghost, y solo cambia tras un reinicio.Listar los kernels instalados
dpkg -l 'linux-image*' | grep '^ii'rpm -q kernel
El primer comando vale para Debian y Ubuntu, el segundo para AlmaLinux, Rocky y RHEL. Si el kernel más reciente de la lista difiere del deuname -r, quizá la corrección está instalada sin estar activa.Saber si hay un reinicio pendiente
cat /var/run/reboot-requiredsudo needrestart -ksudo dnf needs-restarting -r
Los dos primeros sirven en Debian y Ubuntu, el tercero en AlmaLinux y Rocky (paquetednf-utilssi falta el comando). Comparan el kernel en ejecución con el instalado.Buscar los nodos vhost y sus permisos
ls -l /dev/vhost-net /dev/vhost-vsocklsmod | grep '^vhost'getent group kvm
Sin nodo y sin módulo cargado, la vía descrita para Vghost no está abierta en este instante, aunque un programa o un administrador pueden cargar el módulo después. Si existe un nodo, lea su modo:0666significa que cualquier cuenta local puede abrirlo,0660que hay que pertenecer al grupo propietario. Si gestiona máquinas virtuales usted mismo, añadals -l /dev/kvm.Buscar el identificador en el registro de cambios del paquete
apt changelog linux-image-$(uname -r) | grep CVE-2026-74580rpm -q --changelog kernel | grep CVE-2026-74580
La primera línea vale para Debian y Ubuntu, la segunda para la familia RHEL. Encontrar el identificador es buena señal; no encontrarlo no prueba nada, porque el registro puede citar la corrección de otro modo. El tracker de la distribución zanja la duda.Tratar los contenedores y el acceso a dispositivos
docker exec <contenedor> uname -rdocker ps -q | xargs -r docker inspect | grep -E 'Privileged|vhost'
El primer comando muestra el kernel del VPS, prueba de que el contenedor no tiene uno propio. El segundo detecta los contenedores lanzados en modo privilegiado o con un dispositivo vhost montado: ven los nodos del host.
Cómo están las distribuciones
El estado de las correcciones cambia de un día a otro y difiere entre versiones de una misma distribución, porque unas se corrigen antes que otras. Relea el tracker de su distribución para los dos identificadores, CVE-2026-74580 y CVE-2026-99999, antes de concluir: los enlaces están al final del artículo. Para AlmaLinux y Rocky, siga los errata que cada proyecto publica tras los de RHEL. Mientras su versión no muestre una corrección publicada, aplique una medida provisional y vuelva a comprobar.
Actualizar según el entorno
Debian y Ubuntu
sudo apt updatesudo apt full-upgradeapt list --installed 'linux-image*'
Usefull-upgrade: un kernel nuevo llega con un nombre de paquete nuevo, yapt upgradesuele dejarlo de lado ("kept back"). Si el tracker indica que la corrección aún no está publicada para su versión, actualizar no aporta nada en este punto: aplique una medida provisional y vuelva a comprobar con regularidad.AlmaLinux, Rocky y RHEL
sudo dnf upgrade --refresh kernelsudo grubby --default-kernelsudo dnf needs-restarting -r
El segundo comando confirma que el kernel instalado es el que arrancará por defecto. El tercero indica si el sistema espera un reinicio.Docker y contenedores
No hay nada que reconstruir: los contenedores usan el kernel del VPS. Actualice el kernel de la máquina como arriba y reiníciela. Tras el reinicio, compruebe que cada contenedor ha vuelto:
docker psydocker ps -a --filter status=exited. Una políticarestart: unless-stoppeden sus archivos Compose evita relanzar a mano.Hipervisor propio (KVM, Proxmox)
Usted es el host, así que ambos fallos le afectan. Aplique las mismas actualizaciones en el host y reinícielo tras migrar o detener limpiamente las máquinas virtuales. Mantenga el host al día antes que los invitados, no después.
Un kernel instalado no es un kernel en ejecución
Un apt full-upgrade correcto no arregla nada mientras la máquina no se reinicie: el kernel vulnerable sigue cargado en memoria. La única comprobación válida es uname -r tras el reinicio, comparado con el número esperado en el boletín de su distribución. Anótelo en su registro, con la fecha, para cada servidor.
Reiniciar sin cortar los sitios de los clientes
Planifique en lugar de padecer. Elija una ventana tranquila, avise a los clientes, compruebe que sus copias de seguridad son recientes y programe el reinicio: sudo shutdown -r 03:30 "Reinicio del kernel". Antes, anote el estado de los servicios con systemctl --failed y la lista de contenedores con docker ps; después, repita los mismos comandos y compare. Trate el parque por tandas de unas pocas máquinas.
El livepatch puede evitar un reinicio, pero su disponibilidad depende de la distribución y de la suscripción: Canonical Livepatch en Ubuntu con Ubuntu Pro, kpatch en la familia RHEL, KernelCare de un editor externo. No dé por hecho que existe un parche en caliente para estos dos fallos: lea el boletín del proveedor y, en Ubuntu, canonical-livepatch status --verbose. El aviso de Vghost pide reiniciar con el kernel corregido; sin livepatch confirmado, es la única vía.
Medidas provisionales y sus límites
Si la corrección de su distribución aún no está publicada, dos gestos reducen la superficie de Vghost sin cerrarla. El primero retira el acceso general a los nodos, por ejemplo sudo chmod 0660 /dev/vhost-net /dev/vhost-vsock, y mantiene alejados de estos dispositivos a los contenedores no confiables. No revoca los descriptores ya abiertos. El segundo, que la ficha de Red Hat para Vghost propone como medida, impide cargar los módulos: printf 'install vhost_net /bin/false\ninstall vhost_vsock /bin/false\n' | sudo tee /etc/modprobe.d/vhost-off.conf, y luego sudo modprobe -r vhost_net vhost_vsock. Red Hat advierte de que desactivar vhost puede degradar el rendimiento de E/S de las máquinas virtuales, y de que la descarga falla si el controlador está en uso.
Estas medidas no sirven contra PwnEscape, cuyo defecto está en el host, y ninguna sustituye al kernel corregido. Restablezca la configuración original una vez aplicada la corrección.
Comprobar las huellas después
Que sepamos, no se ha publicado ningún indicador de compromiso propio de estos fallos, lo que hace imperfecta la comprobación. Aun así, revise lo que puede delatar una escalada de privilegios reciente: sudo journalctl -k --since "30 days ago" | grep -i -E 'vhost|oops|general protection' para anomalías del kernel, last -x | head -30 para accesos y reinicios, sudo awk -F: '$3==0' /etc/passwd para cuentas de nivel root, y después las claves de /root/.ssh/authorized_keys y las tareas crontab -l de root. Busque también binarios setuid recientes con sudo find / -xdev -perm -4000 -mtime -30.
Un atacante que se ha vuelto root puede borrar sus huellas: una comprobación limpia no prueba que todo esté sano. Si duda de un servidor que ha ejecutado código no confiable, reconstrúyalo desde una imagen limpia y restaure los datos en lugar de limpiarlo.
Para una agencia: una ventana común, no un servidor tras otro
Con decenas de VPS en clientes distintos, el comando de actualización tarda un minuto; el tiempo se va en saber qué servidor corre qué kernel, quién valida el reinicio y cuándo. Lleve un registro vivo alimentado con uname -r y con la presencia de /var/run/reboot-required, y fije una ventana común anunciada con antelación en lugar de descubrir el fallo servidor por servidor. Clasifique primero las máquinas donde se ejecuta código de clientes no confiable, y después aquellas donde existe /dev/vhost-*.
El área de agencia de ServOrbit centraliza servicios y vencimientos, de modo que no hay que seguirlos cuenta por cuenta. Para quien prefiera no gestionar el kernel por sí mismo, ServOrbit ofrece la opción de administración de VPS; esta guía, por su parte, se ofrece sin soporte.
La documentación oficial
Divulgación de Vghost en oss-security: https://openwall.com/lists/oss-security/2026/10/14/2
Análisis técnico de Vghost: https://matrix.tencent.com/en/2026/10/12/vghost-cve-2026-74580
Registro CVE de PwnEscape: https://cveawg.mitre.org/api/cve/CVE-2026-99999
Artículo del descubridor de PwnEscape: https://pwn.ai/blog/pwnescape
Tracker de Debian para Vghost: https://security-tracker.debian.org/tracker/CVE-2026-74580
Tracker de Debian para PwnEscape: https://security-tracker.debian.org/tracker/CVE-2026-99999
Tracker de Ubuntu para Vghost: https://ubuntu.com/security/CVE-2026-74580
Tracker de Ubuntu para PwnEscape: https://ubuntu.com/security/CVE-2026-99999
Ficha de Red Hat para Vghost: https://access.redhat.com/security/cve/CVE-2026-74580
Errata de AlmaLinux: https://errata.almalinux.org/
Canonical Livepatch: https://ubuntu.com/security/livepatch
Herramienta needrestart: https://github.com/liske/needrestart
