PRNextDurante la noche del 4 al 5 de noviembre 2026, hora de París, aplicamos actualizaciones de LTS de rutina Ubuntu 26.04 a dos instancias de VPS y verificamos su regreso al servicio. La intervención cubrió actualizaciones de paquetes 83: 23 en un servidor y 60 en el otro.
Esta cuenta cubre el mantenimiento del sistema. La corrección del kernel asociada con CVE-2026-98432 se instaló durante una intervención separada el 3 de noviembre. Las dos operaciones tienen propósitos diferentes y evidencia de validación separada.
Los paquetes procedían de los repositorios habituales Ubuntu, cuyos metadatos firmados fueron verificados. Antes de la instalación, comparamos las versiones instaladas, las versiones disponibles y los cambios esperados. El resultado final coincide con las actualizaciones 83 planificadas, sin agregar ni eliminar paquetes.
Systemd ahora tiene la versión 259.9-0ubuntu0.1. El sistema operativo sigue siendo Ubuntu 26.04 LTS. Esta intervención mantiene el kernel existente, las versiones Node.js, Docker y PostgreSQL, junto con las versiones de la aplicación ya implementadas. No requiere ninguna actualización del paquete PRNext npm en sus proyectos.
Después del reinicio, ambos servidores aún ejecutan 7.0.0-43-generic de los paquetes Ubuntu 7.0.0-43.43 instalados el 3 de noviembre. Esos paquetes oficiales se seleccionaron del bolsillo de prueba propuesto tras una decisión específica y controles específicos, sin habilitar ese bolsillo a nivel mundial.
Cuando se verificó el 5 de noviembre, el rastreador oficial de Ubuntu todavía describe esta versión como en proceso de calificación para Ubuntu 26.04 LTS. Por lo tanto, las actualizaciones del paquete 83 en este mantenimiento no constituyen una nueva corrección de CVE-2026-98432. Nuestro artículo anterior explica la decisión del kernel y la distinción entre un paquete disponible, su canal de distribución y el kernel que realmente se está ejecutando.
Reemplazar una biblioteca en el disco no renueva automáticamente la copia ya cargada por un proceso en ejecución. Después de la instalación, nuestras comprobaciones aún encontraron servicios que utilizan bibliotecas antiguas. Por lo tanto, reiniciamos las instancias de VPS en secuencia, verificando la primera antes de continuar con la segunda.
Después de cada reinicio, una nueva conexión SSH confirmó que había regresado el acceso administrativo. Las comprobaciones finales indicaron que ningún servicio seguía utilizando las antiguas bibliotecas. Se conservaron la configuración SSH y el acceso existente. Es por eso que un reinicio fue parte de este trabajo a pesar de que no se instaló ningún kernel nuevo durante el mantenimiento.
Verificamos la resolución de DNS, las respuestas públicas de HTTPS y la preparación de PostgreSQL, incluida una consulta simple que confirma que la base de datos respondió. Los cinco puntos finales de aplicaciones nativas también arrojaron respuestas HTTPS 200 con verificación normal TLS.
Inicialmente, tres contenedores estaban inactivos después del reinicio. Las solicitudes HEAD a sus direcciones nativas los despertaron a través del mecanismo normal de la plataforma. Luego se observó que los cinco contenedores funcionaban con los mismos identificadores e imágenes. Estas comprobaciones establecen que los puntos finales probados volvieron al servicio; no validan todos los flujos de trabajo comerciales dentro de una aplicación.
El filtrado de red temporal y la configuración MPTCP se mantuvieron. Verificamos las reglas después del arranque y confirmamos que MPTCP estaba deshabilitado en todos los espacios de nombres de red observados, incluso después de que los contenedores se despertaron. Esas protecciones conservan sus limitaciones y no reemplazan la corrección del kernel.
Siete paquetes en cada servidor permanecieron sujetos al lanzamiento gradual de Ubuntu. Conservamos este mecanismo sin forzar su instalación. La documentación de Ubuntu explica que distribuye algunas actualizaciones en etapas para limitar el impacto de una posible regresión.
La misma documentación afirma que las actualizaciones de seguridad nunca se realizan por fases. Por lo tanto, un mensaje sobre paquetes diferidos exige verificar su estado real en lugar de aplicar un comando general para eludir esa protección.
Los paquetes 83 reflejan el estado de nuestros servidores en el momento de la intervención. Su distribución, repositorios y software instalado producirán un resultado diferente. Compare el plan de actualización propuesto con su instalación, prepare una opción de recuperación y verifique los servicios de los que depende su aplicación después de renovarlos.
Esta es una cuenta anticuada: las versiones disponibles hoy pueden cambiar mañana. Para el kernel, consulte el rastreador de Ubuntu para conocer la vulnerabilidad y su familia de paquetes. Para la aplicación, ejerza también las funciones que sean importantes para sus usuarios. Una respuesta HTTP exitosa proporciona evidencia útil cuyo alcance debe permanecer claro.
CVE-2026-98432: por qué es importante la espera, Ubuntu corrige la propuesta y la diferencia entre mitigación, un paquete disponible y un kernel en ejecución parcheado.
PRNextLo que verificamos en dos instancias de Ubuntu VPS: nftables, MPTCP, contenedores y estado del servicio. Medidas temporales mientras se espera una corrección del kernel Linux.
PRNextImplemente una aplicación Next.js en un VPS Linux con un servidor de producción, systemd, un proxy inverso y verificaciones antes de cambiar el tráfico.
PRNext