# CVE-2026-98432: cuando esperar una corrección del kernel se convierte en una preocupación Han pasado diecinueve días desde que Ubuntu publicó su entrada CVE-2026-98432 el 15 de octubre. Para un equipo que opera servicios conectados a Internet, esa espera es demasiado larga y preocupante. Nuestra propia intervención comenzó el 30 de octubre con medidas temporales. El 3 de noviembre, cuatro días después, instalamos la solución oficial en ambas instancias de VPS y verificamos que se habían iniciado en el kernel 7.0.0-43-generic. Estos paquetes Ubuntu provienen del bolsillo de prueba propuesto. La calificación general anunciada por Ubuntu aún está en progreso: nuestra instalación verificada no convierte estos paquetes en una actualización ya distribuida a través de los canales estables habituales. ## Por qué es importante la espera Una aplicación sigue respondiendo. Sus certificados son válidos. Los despliegues tienen éxito. Ninguno de esos resultados establece que se haya solucionado una falla en el kernel que recibe las conexiones de red. Un servicio puede parecer completamente normal mientras la respuesta de seguridad permanece inconclusa. Para un administrador, cada día adicional significa mantener una decisión provisional, seguir los anuncios y preparar una intervención. Ese período es nuestra preocupación. No apoya ni una acusación infundada de negligencia ni permite que una medida temporal se convierta en permanente por negligencia. ## Existe una solución, pero su canal de distribución importa El anuncio Ubuntu publicado el 2 de noviembre describe correcciones en el bolsillo de prueba propuesto para varias versiones compatibles. Para Ubuntu 26.04 LTS y el paquete Linux, denomina versión 7.0.0-43.43.. El anuncio dice que la publicación en las actualizaciones seguirá a las pruebas, sin dar una fecha firme. Eso cambia la forma en que se debe describir la situación. Decir que no existe ninguna solución sería inexacto. Decir que cada Ubuntu VPS ya está parcheado sería igualmente inexacto. Un paquete que se está probando, su disponibilidad a través de los canales de actualización habituales y su uso real en una máquina son hechos separados. [Ubuntu anuncio publicado el 2 de noviembre](https://ubuntu.com/blog/fixes-available-in-proposed-pocket-for-cve-2026-98432) ## -propuesto todavía requiere una decisión de producción Canonical describe el acceso temprano a los núcleos propuestos como una opción para los equipos capaces de realizar sus propias pruebas de aceptación. Este canal permite que el trabajo comience antes. No establece que el proceso de calificación más amplio esté completo. En un VPS que sirve aplicaciones reales, la decisión también implica el reinicio, los controladores, la conexión en red y la recuperación. Habilitar ampliamente un repositorio y actualizarlo sin revisar los paquetes seleccionados puede ampliar la intervención más allá de la solución prevista. Por lo tanto, este artículo no proporciona un comando general para cambiar una máquina de producción a -propuesta. La pregunta útil no es simplemente si hay una solución disponible. Es qué canal lo proporciona, para qué distribución y tipo de núcleo, y con qué validación. [acceso temprano a los núcleos propuestos](https://canonical.com/blog/accelerating-delivery-of-cve-fixes-with-a-new-kernel-release-strategy) ## Ambas instancias de VPS están ejecutando el kernel parcheado. El VPS TinyDigit pasó de 7.0.0-38-generic a 7.0.0-43-generic. El VPS PRNext pasó de 7.0.0-28-genérico a 7.0.0-43-genérico. En cada servidor, instalamos cuatro paquetes de kernel Ubuntu en la versión 7.0.0-43.43, luego verificamos el kernel en ejecución real después del reinicio. La instalación se limitó a esos paquetes, sin una actualización de distribución ni una habilitación global propuesta. Los kernels anteriores siguen estando disponibles como respaldo de arranque. El filtrado de red temporal y la configuración MPTCP también se conservan durante este seguimiento. Después de los reinicios, abrimos una nueva conexión SSH a cada servidor y verificamos las respuestas HTTPS de los puntos finales PRNext y TinyDigit probados. Los cinco contenedores de solicitud originales están presentes y listos; sus cinco alias nativos también responden a través de HTTPS. Una dependencia externa sigue no disponible; Aún es necesario verificar la recuperación completa de la aplicación. ## Verifique el kernel que realmente se está ejecutando El paquete del kernel instalado en el disco puede diferir del kernel que se está ejecutando actualmente. Después de una intervención, la verificación debe cubrir el sistema en ejecución, el acceso SSH nuevo, HTTPS y las aplicaciones que aloja. Una salida exitosa del administrador de paquetes no es suficiente para cerrar el trabajo. Estos comandos no modifican el servidor. Proporcionan un punto de partida para comparar con el rastreador oficial de la distribución. Un número de versión por sí solo, sin la identidad del paquete y las correcciones respaldadas por la distribución, no puede establecer el resultado. ```bash uname -r cat /etc/os-release ``` ## La mitigación no es una reparación del kernel Nuestra guía original recoge las medidas temporales aplicadas el 30 de octubre y los controles realizados posteriormente. Sigue siendo un relato histórico, en lugar de una evidencia del estado actual de cada instancia de VPS. Deshabilitar MPTCP no repara la falla subyacente. El rastreador de Ubuntu también describe los límites del filtrado de opciones específicas de IPv4. Una regla cargada, un contador de paquetes o un sitio web accesible no garantizan protección contra todas las rutas de explotación. [guía original](/es/blog/cve-2026-98432-ubuntu-vps-mitigation) ## Lo que debería decirle una actualización de seguridad útil Es razonable esperar una explicación clara de lo que se ha solucionado, lo que aún se está probando y lo que queda por hacer en las propias máquinas. Es igualmente importante reconocer el costo de implementar una actualización del kernel sin una validación suficiente. Urgencia y estabilidad pertenecen a la misma decisión. Nuestra posición es simple: una medida provisional debe seguir siendo visible en el trabajo que aún queda por hacer. El punto final debería ser una versión parcheada que realmente se ejecute con servicios verificados, en lugar de un simple anuncio tranquilizador. Una actualización npm a PRNext no puede realizar esa tarea del sistema Linux. ## Sources [Ubuntu · CVE-2026-98432](https://ubuntu.com/security/CVE-2026-98432) [Ubuntu · Fixes available in -proposed, 2 November 2026](https://ubuntu.com/blog/fixes-available-in-proposed-pocket-for-cve-2026-98432) [Canonical · Kernel release strategy](https://canonical.com/blog/accelerating-delivery-of-cve-fixes-with-a-new-kernel-release-strategy) [Ubuntu · SRU verification](https://ubuntu.com/project/docs/SRU/reference/sru-verification/) Publicado: 2026-11-03 Modificado: 2026-11-03 Autor: PRNext --- Idioma: es Canonical: https://prnext.dev/es/blog/cve-2026-98432-ubuntu-waiting-for-kernel-fix Index: https://prnext.dev/llms.txt