[{"data":1,"prerenderedAt":193},["ShallowReactive",2],{"seo-verification":3,"blog-pwnescape-vghost-kernel-linux-vps-actualizar-es":6},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-pwnescape-vghost-kernel-linux-vps-actualizar-es",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":30,"intro":33,"sections":34,"ctaTitle":139,"ctaBody":140,"ctaButton":141,"ctaUrl":142,"relatedPosts":143},517,"pwnescape-vghost-kernel-linux-vps-actualizar",{"fr":12,"en":13,"ar":14,"es":10},"pwnescape-vghost-noyau-linux-vps-mettre-a-jour","pwnescape-vghost-linux-kernel-vps-update","ثغرتا-pwnescape-و-vghost-تحديث-نواة-لينكس-على-vps","PwnEscape y Vghost: actualizar el kernel Linux de un VPS","Dos fallos del kernel Linux de octubre de 2026: PwnEscape lo corrige el proveedor, Vghost su VPS. Comprobar el kernel, actualizar y planificar el reinicio.",11,0,false,"2026-10-28T00:00:00+00:00","2026-10-29T03:10:22+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},8,"Seguridad y monitorización","securite-monitoring","bg-rose-500\u002F10 text-rose-400","security",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fpwnescape-vghost-noyau-linux-vps-mettre-a-jour-poster.svg","A mediados de octubre de 2026 se hicieron públicos dos fallos del kernel Linux: PwnEscape, que permite a una máquina virtual escapar hacia su host, y Vghost, una escalada local a root con prueba de concepto pública. En un VPS la cuestión no es si hay que actualizar, sino quién actualiza qué. El host de virtualización es cosa del proveedor; el kernel de su VPS es cosa suya, y solo se corrige al reiniciar. Esta guía da los comandos por distribución, la comprobación de exposición y un plan de reinicio que respeta los sitios de los clientes.",[35,39,74,77,80,102,105,120,124,127,130,133,136],{"type":36,"title":37,"body":38},"h2","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.\n\nVghost 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 `\u002Fdev\u002Fvhost-net` o `\u002Fdev\u002Fvhost-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.",{"type":40,"title":41,"headers":42,"rows":46},"comparison","Quién corrige qué",[43,44,45],"Caso","Dónde está el defecto","Quién actúa",[47,51,55,59,63,67,71],[48,49,50],"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",[52,53,54],"Vghost (CVE-2026-74580), lado VPS","Kernel de su VPS, si los nodos `\u002Fdev\u002Fvhost-*` son alcanzables","Usted: kernel corregido y reinicio",[56,57,58],"Vghost, vía desencadenada desde un invitado","Kernel y QEMU del host, bajo condiciones precisas","El proveedor",[60,61,62],"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",[64,65,66],"Servidor dedicado o VPS donde usted es el hipervisor (KVM, Proxmox)","Usted es el host","Usted: ambos fallos le afectan",[68,69,70],"Contenedores Docker en el VPS","Comparten el kernel del VPS","Corregir el kernel del VPS; reconstruir una imagen no cambia nada",[72,73,58],"Hosting compartido cPanel","Kernel gestionado por el proveedor",{"type":36,"title":75,"body":76},"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.\n\nEn 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.",{"type":36,"title":78,"body":79},"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.\n\nTodo depende de los permisos de los nodos vhost. Según el anuncio de oss-security, en las pruebas de su autor, Ubuntu limitaba `\u002Fdev\u002Fvhost-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.",{"type":81,"title":82,"steps":83},"steps","Comprobar el kernel y la exposición en diez minutos",[84,87,90,93,96,99],{"title":85,"body":86},"Leer el kernel en ejecución","`uname -r`\nEste 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.",{"title":88,"body":89},"Listar los kernels instalados","`dpkg -l 'linux-image*' | grep '^ii'`\n`rpm -q kernel`\nEl 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 de `uname -r`, quizá la corrección está instalada sin estar activa.",{"title":91,"body":92},"Saber si hay un reinicio pendiente","`cat \u002Fvar\u002Frun\u002Freboot-required`\n`sudo needrestart -k`\n`sudo dnf needs-restarting -r`\nLos dos primeros sirven en Debian y Ubuntu, el tercero en AlmaLinux y Rocky (paquete `dnf-utils` si falta el comando). Comparan el kernel en ejecución con el instalado.",{"title":94,"body":95},"Buscar los nodos vhost y sus permisos","`ls -l \u002Fdev\u002Fvhost-net \u002Fdev\u002Fvhost-vsock`\n`lsmod | grep '^vhost'`\n`getent group kvm`\nSin 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: `0666` significa que cualquier cuenta local puede abrirlo, `0660` que hay que pertenecer al grupo propietario. Si gestiona máquinas virtuales usted mismo, añada `ls -l \u002Fdev\u002Fkvm`.",{"title":97,"body":98},"Buscar el identificador en el registro de cambios del paquete","`apt changelog linux-image-$(uname -r) | grep CVE-2026-74580`\n`rpm -q --changelog kernel | grep CVE-2026-74580`\nLa 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.",{"title":100,"body":101},"Tratar los contenedores y el acceso a dispositivos","`docker exec \u003Ccontenedor> uname -r`\n`docker ps -q | xargs -r docker inspect | grep -E 'Privileged|vhost'`\nEl 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.",{"type":36,"title":103,"body":104},"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.",{"type":81,"title":106,"steps":107},"Actualizar según el entorno",[108,111,114,117],{"title":109,"body":110},"Debian y Ubuntu","`sudo apt update`\n`sudo apt full-upgrade`\n`apt list --installed 'linux-image*'`\nUse `full-upgrade`: un kernel nuevo llega con un nombre de paquete nuevo, y `apt upgrade` suele 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.",{"title":112,"body":113},"AlmaLinux, Rocky y RHEL","`sudo dnf upgrade --refresh kernel`\n`sudo grubby --default-kernel`\n`sudo dnf needs-restarting -r`\nEl segundo comando confirma que el kernel instalado es el que arrancará por defecto. El tercero indica si el sistema espera un reinicio.",{"title":115,"body":116},"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 ps` y `docker ps -a --filter status=exited`. Una política `restart: unless-stopped` en sus archivos Compose evita relanzar a mano.",{"title":118,"body":119},"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.",{"type":121,"title":122,"body":123},"tip","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.",{"type":36,"title":125,"body":126},"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.\n\nEl 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.",{"type":36,"title":128,"body":129},"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 \u002Fdev\u002Fvhost-net \u002Fdev\u002Fvhost-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 \u002Fbin\u002Ffalse\\ninstall vhost_vsock \u002Fbin\u002Ffalse\\n' | sudo tee \u002Fetc\u002Fmodprobe.d\u002Fvhost-off.conf`, y luego `sudo modprobe -r vhost_net vhost_vsock`. Red Hat advierte de que desactivar vhost puede degradar el rendimiento de E\u002FS de las máquinas virtuales, y de que la descarga falla si el controlador está en uso.\n\nEstas 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.",{"type":36,"title":131,"body":132},"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' \u002Fetc\u002Fpasswd` para cuentas de nivel root, y después las claves de `\u002Froot\u002F.ssh\u002Fauthorized_keys` y las tareas `crontab -l` de root. Busque también binarios setuid recientes con `sudo find \u002F -xdev -perm -4000 -mtime -30`.\n\nUn 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.",{"type":36,"title":134,"body":135},"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 `\u002Fvar\u002Frun\u002Freboot-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 `\u002Fdev\u002Fvhost-*`.\n\nEl á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.",{"type":36,"title":137,"body":138},"La documentación oficial","Divulgación de Vghost en oss-security: https:\u002F\u002Fopenwall.com\u002Flists\u002Foss-security\u002F2026\u002F10\u002F14\u002F2\n\nAnálisis técnico de Vghost: https:\u002F\u002Fmatrix.tencent.com\u002Fen\u002F2026\u002F10\u002F12\u002Fvghost-cve-2026-74580\n\nRegistro CVE de PwnEscape: https:\u002F\u002Fcveawg.mitre.org\u002Fapi\u002Fcve\u002FCVE-2026-99999\n\nArtículo del descubridor de PwnEscape: https:\u002F\u002Fpwn.ai\u002Fblog\u002Fpwnescape\n\nTracker de Debian para Vghost: https:\u002F\u002Fsecurity-tracker.debian.org\u002Ftracker\u002FCVE-2026-74580\n\nTracker de Debian para PwnEscape: https:\u002F\u002Fsecurity-tracker.debian.org\u002Ftracker\u002FCVE-2026-99999\n\nTracker de Ubuntu para Vghost: https:\u002F\u002Fubuntu.com\u002Fsecurity\u002FCVE-2026-74580\n\nTracker de Ubuntu para PwnEscape: https:\u002F\u002Fubuntu.com\u002Fsecurity\u002FCVE-2026-99999\n\nFicha de Red Hat para Vghost: https:\u002F\u002Faccess.redhat.com\u002Fsecurity\u002Fcve\u002FCVE-2026-74580\n\nErrata de AlmaLinux: https:\u002F\u002Ferrata.almalinux.org\u002F\n\nCanonical Livepatch: https:\u002F\u002Fubuntu.com\u002Fsecurity\u002Flivepatch\n\nHerramienta needrestart: https:\u002F\u002Fgithub.com\u002Fliske\u002Fneedrestart","Un parque de VPS, una sola ventana de reinicio","Un parque de servidores de clientes se gestiona mejor desde un solo lugar. En el área de agencia de ServOrbit.com, centraliza servicios y vencimientos; la opción de administración de VPS existe para quien prefiera no gestionar el kernel por sí mismo.","Descubrir la oferta para agencias","\u002Fsolutions\u002Fagences",[144,160,177],{"id":145,"slug":146,"slugs":147,"title":151,"excerpt":152,"readTime":17,"views":153,"isPinned":19,"publishedAt":154,"updatedAt":155,"category":156,"categories":157,"featuredImage":30,"bgImage":31,"posterImage":159,"relatedSolution":30},317,"hardening-linux-vps-checklist-para-agencias-tras-la-entrega",{"fr":148,"en":149,"ar":150,"es":146},"linux-hardening-vps-checklist","linux-vps-hardening-checklist-for-agencies","قائمة-تصليب-خادم-لينكس-للوكالات-بعد-التسليم","Hardening Linux VPS : checklist para agencias tras la entrega","Checklist de hardening Linux reproducible para agencias: auditd, sudo, clave SSH, UFW, fail2ban y desactivación de root — con trazabilidad por cliente.",1,"2026-08-30T00:00:00+00:00","2026-09-07T11:26:10+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[158],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Flinux-hardening-vps-checklist-poster.svg",{"id":161,"slug":162,"slugs":163,"title":167,"excerpt":168,"readTime":169,"views":170,"isPinned":19,"publishedAt":171,"updatedAt":172,"category":173,"categories":174,"featuredImage":30,"bgImage":31,"posterImage":176,"relatedSolution":30},382,"actualizaciones-seguridad-vps-debian-ubuntu",{"fr":164,"en":165,"ar":166,"es":162},"securite-vps-mises-a-jour-automatiques-debian-ubuntu","vps-automatic-security-updates-debian-ubuntu","تحديثات-أمان-تلقائية-vps-debian-ubuntu","Actualizaciones de seguridad automáticas en VPS Debian\u002FUbuntu","Configure unattended-upgrades en sus VPS Debian\u002FUbuntu para automatizar los parches de seguridad y reducir la superficie de ataque en su flota de clientes.",10,2,"2026-09-26T00:00:00+00:00","2026-09-29T14:40:42+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[175],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fsecurite-vps-mises-a-jour-automatiques-debian-ubuntu-poster.svg",{"id":178,"slug":179,"slugs":180,"title":184,"excerpt":185,"readTime":186,"views":153,"isPinned":19,"publishedAt":187,"updatedAt":188,"category":189,"categories":190,"featuredImage":30,"bgImage":31,"posterImage":192,"relatedSolution":30},494,"openssh-10-6-actualizacion-seguridad-sshd",{"fr":181,"en":182,"ar":183,"es":179},"openssh-10-6-mise-a-jour-securite-sshd","openssh-10-6-security-update-sshd","تحديث-openssh-10-6-أمان-sshd","OpenSSH 10.6: actualizar sshd sin perder el acceso","Actualización de seguridad OpenSSH 10.6: comprobar la versión realmente activa, qué puede romperse (ProxyCommand, Compression) y recargar sshd sin riesgo.",12,"2026-10-22T00:00:00+00:00","2026-10-23T13:27:02+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[191],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fopenssh-10-6-mise-a-jour-securite-sshd-poster.svg",1793251484802]