PRNextUna vulnerabilidad del kernel no se puede solucionar en package.json. Después de la alerta CVE-2026-98432, verificamos dos instancias de VPS Ubuntu y aplicamos una mitigación específica. Aquí está nuestro enfoque, los comandos útiles y los límites que importan.
El objetivo es reducir la exposición mientras se espera un kernel parcheado y luego verificar que los servicios sigan siendo accesibles. Este artículo documenta una intervención real; Adapte la configuración a su propio servidor.
El 3 de noviembre, instalamos la solución oficial Ubuntu en ambas instancias de VPS. Ahora están ejecutando el kernel 7.0.0-43-generic después de reiniciar y verificar el acceso SSH nuevo, los sitios HTTPS y las aplicaciones probadas. Estos paquetes provienen de -propuesto: esto no significa que Ubuntu haya completado la calificación general o la distribución a través de los canales estables. Una dependencia externa sigue no disponible; Aún es necesario verificar la recuperación completa de la aplicación.
Las siguientes secciones conservan el relato de nuestra mitigación de octubre 30. El seguimiento de noviembre de 3 detalla la instalación específica, las comprobaciones después del reinicio y la distinción entre los cuatro días desde nuestra mitigación hasta la instalación de la solución y los diecinueve días desde que se publicó la entrada de Ubuntu.
Lea el seguimiento de noviembre de 3 y ambos resultados de VPS
Estos comandos identifican el kernel en ejecución, la distribución, dos configuraciones de red y los sockets MPTCP de escucha. No cambian la configuración. Si su versión de ss carece de soporte MPTCP, un error no significa que el servidor esté protegido.
Compare los resultados con el rastreador de seguridad de su distribución. Una versión del kernel copiada de una publicación en las redes sociales no es suficiente: las distribuciones pueden incluir correcciones en sus propios paquetes. Un paquete instalado tampoco es necesariamente el kernel que se está ejecutando actualmente.
uname -r
cat /etc/os-release
sysctl net.mptcp.enabled net.ipv4.tcp_migrate_req
sudo ss -M -l -n -pEl 30 de octubre, auditamos nuestras dos instancias de VPS Ubuntu y aplicamos medidas temporales específicas. Agregamos un filtro dedicado para paquetes TCP IPv4 que llevan opciones de IP y deshabilitamos la creación de sockets MPTCP en los espacios de nombres de red relevantes.
Un servicio Caddy tuvo un reinicio controlado para recrear sus sockets con la configuración ajustada. Los cinco contenedores existentes mantuvieron sus procesos y tiempos de inicio. Luego verificamos conexiones SSH nuevas y recibimos HTTPS 200 respuestas de los siete sitios que probamos.
No actualizamos el sistema operativo ni reiniciamos ninguno de los VPS. Estos resultados describen nuestros controles después de la intervención; no prueban que todos los caminos posibles de explotación estén bloqueados.
Esta es la estructura de nuestro filtro, usando un nombre de tabla de ejemplo. La primera regla limita la tala; el segundo descarta todos los paquetes coincidentes incluso después de alcanzar ese límite. Las opciones de IP difieren de las opciones de TCP ordinarias como MSS o SACK.
Trate esto como un ejemplo para revisar e integrar en su firewall existente, con acceso de recuperación y una reversión de alcance lista. No reemplace toda su configuración. Verifique los requisitos especiales de la red, incluidas las opciones de IP utilizadas para el etiquetado de seguridad.
Este filtro tiene como objetivo IPv4. Lo describimos como reducción de exposición, sin garantía de que cubra la vulnerabilidad por completo.
table inet cve_2026_98432 {
chain prerouting {
type filter hook prerouting priority -310; policy accept;
ip protocol tcp ip hdrlength > 5 limit rate 5/minute burst 5 packets log prefix "CVE98432 IPopts " level warn
ip protocol tcp ip hdrlength > 5 counter drop
}
}Si sus servicios no necesitan MPTCP, esta configuración evita nuevos sockets MPTCP en el espacio de nombres de la red actual. No cierra enchufes que ya están abiertos. Verifique los sockets nuevamente y planifique reinicios solo para los servicios afectados.
Para mantener esta configuración en el arranque, agregue net.mptcp.enabled = 0 a un archivo sysctl.d dedicado después de verificar la configuración existente. Luego se debe probar la persistencia durante un reinicio planificado.
sudo sysctl -w net.mptcp.enabled=0Go 1.24 habilitó MPTCP de forma predeterminada para ListenConfig en sistemas compatibles. Por lo tanto, vale la pena verificar un proxy inverso escrito en Go incluso cuando su aplicación usa Node.js.
La siguiente configuración cambia el valor predeterminado cuando se proporciona en el entorno de servicio. Conserve cualquier otro valor de GODEBUG y vuelva a crear los sockets del proceso afectado. Lo usamos para Caddy; no reemplaza una corrección del kernel.
GODEBUG=multipathtcp=0La configuración MPTCP pertenece a cada espacio de nombres de red. Por lo tanto, un valor cero en el host no establece que todos los contenedores tengan la misma configuración.
Verificamos los espacios de nombres existentes y agregamos una verificación periódica para detectar nuevos. Una prueba que utilizó un espacio de nombres creado después de la activación confirmó que se había manejado. Esta verificación es periódica, por lo que hay un retraso antes de que se aplique, lo cual es una de las razones por las que también seguimos filtrando el ingreso del host.
Pueden quedar algunos enchufes internos del contenedor previamente abiertos. Distinguimos esos enchufes de los oyentes públicos en lugar de tratar la configuración del sistema como evidencia de que cada enchufe había desaparecido.
Verificamos que el filtro estuviera cargado, inspeccionamos sus contadores y revisamos la configuración y los oyentes de MPTCP. Un paquete de diagnóstico sin exploits confirmó que se alcanzó la regla de eliminación. No ejecutamos código de explotación.
También abrimos una nueva conexión SSH y verificamos los sitios externamente. Se conservaron las reglas de firewall existentes. Los mecanismos de persistencia se configuraron y recargaron, pero no los probamos después de un reinicio completo del VPS.
Un contador creciente establece que un paquete coincide con una regla. No demuestra ni un intento de intrusión ni una protección completa: nuestros propios controles de diagnóstico también pueden aumentarlo.
La solución oficial de su distribución sigue siendo la prioridad. Cuando esté disponible para su sistema, planifique su instalación y el reinicio requerido, luego verifique el kernel en ejecución real con uname -r. Decida si desea eliminar medidas temporales según el estatus oficial y los requisitos de sus servicios.
Este trabajo se refiere a la infraestructura Linux que aloja sus aplicaciones. Una actualización de npm a PRNext no puede parchear un kernel de VPS. El autohospedaje también significa seguir esta capa del sistema y comparar los cambios con los servicios reales.
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.
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.
PRNextCompare un servidor Node en un VPS, contenedores, exportación estática y plataformas administradas para alojar Next.js según las necesidades reales de su aplicación.
PRNext