Fallo crítico en Linux CVE-2026-98432: qué revisar en Proxmox y Odoo

,
0

Un fallo crítico en el kernel de Linux, la CVE-2026-98432, puede permitir ejecutar código de forma remota y sin autenticación en un servidor a través de sus conexiones TCP sobre IPv4. Está presente desde Linux 4.4, así que afecta a muchos servidores Linux, entre ellos los hosts Proxmox y las máquinas donde corre Odoo. Se publicó el 15 de octubre y los parches han llegado de forma desigual: Proxmox publicó su aviso el 31 de octubre, mientras que Ubuntu seguía el 3 de noviembre con la corrección en curso.

Qué ha pasado y cómo de grave es

Es un error de memoria (use-after-free) en el código que establece las conexiones TCP sobre IPv4; según IT-Connect, IPv6 no se ve afectado en este escenario. Ubuntu y Red Hat le dan una puntuación CVSS de 9,8, aunque Red Hat la había valorado al principio como moderada.

Conviene leer esa nota con contexto:

  • El hallazgo es de un investigador de Anthropic. Su demostración atacaba un servidor con un servicio MPTCP (TCP de múltiples rutas) a la escucha y tardó cerca de una hora en conseguir ejecutar un comando como root. Anthropic no publicó su código.
  • Eso no permite descartar el resto de los servidores: el equipo de seguridad de Go advierte de que los sistemas sin ese servicio también podrían ser vulnerables.
  • A 2 de noviembre no constaba explotación activa ni figuraba en el catálogo KEV de CISA.

No hay motivo para el pánico, pero sí para parchear en los próximos días, empezando por lo que esté expuesto a internet.

Estado de los parches a 3 de noviembre

Sistema Estado
Proxmox VE y Proxmox Backup Server Corregido en proxmox-kernel 7.0.14-25 o posterior (aviso PSA-2026-00080-1)
Debian 13 y 12 Corregido (6.12.113-1 y 6.1.190-1, o posteriores)
RHEL 8, 9 y 10 Corregido el 1 de noviembre, según IT-Connect; quedaban pendientes el kernel de tiempo real de RHEL 9 y CoreOS
Ubuntu 22.04, 24.04 y 26.04 Corrección en curso según Ubuntu; GBHackers la sitúa en el repositorio -proposed, que no se instala por defecto
Ubuntu 16.04, 18.04 y 20.04 Vulnerable, sin versión corregida indicada

Cambia cada pocos días: consulta la página de tu distribución en las fuentes.

Qué revisar en Proxmox

Instalar el kernel no basta: hasta que el host no arranca con él, sigue expuesto.

  1. Comprueba el kernel en ejecución con uname -r. Tiene que ser 7.0.14-25-pve o superior.
  2. Actualiza y reinicia con apt update y apt full-upgrade, o desde la interfaz web. Si tienes un kernel fijado, el host seguirá arrancando el antiguo: se libera con proxmox-boot-tool kernel unpin.
  3. Revisa las máquinas virtuales una a una. Cada VM Linux tiene su propio kernel y necesita el parche de su distribución. Los contenedores LXC comparten el del host y quedan cubiertos al reiniciarlo.
  4. Si usas otra serie de kernel (6.17 o 6.14), no hay confirmación de que esté corregida: pasa a la serie 7.0 o revisa su registro de cambios.

Reiniciar un clúster sin parar el servicio

  1. Vacía el nodo: migra en vivo las VM o activa el modo de mantenimiento de HA con ha-manager crm-command node-maintenance enable <nodo>. Los LXC no migran en vivo: se reinician en el nodo de destino.
  2. Reinicia el nodo y confirma el kernel con uname -r.
  3. Desactiva el modo de mantenimiento y pasa al siguiente. Si usas Ceph, espera a HEALTH_OK antes de continuar.

Si sigues en Proxmox VE 8

Proxmox VE 8 terminó su soporte el 31 de agosto. No hemos encontrado confirmación de un parche para esta CVE en su kernel 6.8, y el personal de Proxmox ya recordó en octubre, a propósito de otra vulnerabilidad, que esa versión está fuera de soporte.

Nuestra recomendación es planificar la subida a Proxmox VE 9 sin improvisar, pero sin dejarla pasar: copias de seguridad verificadas, pve8to9 --full sin errores, nodos de uno en uno y atención al hardware con passthrough o drivers no oficiales. Mientras tanto, limita al máximo lo que el host expone a la red.

Si tienes Odoo u otras aplicaciones en un servidor Linux

El fallo no está en Odoo, sino en el kernel de la máquina que lo aloja, así que actualizar Odoo no lo resuelve. Recomendamos revisar:

  • Dónde corre. Si está en una VM, aplica el parche de esa VM aunque el host Proxmox ya esté corregido. Si lo gestiona un tercero, pregúntale por escrito qué kernel tiene en ejecución.
  • Ubuntu. Mientras no se publique el paquete definitivo, apt upgrade no te dará la corrección. Vigila la página de Ubuntu.
  • Servicios MPTCP. ss -lM muestra si hay alguno a la escucha. Desde Go 1.24, los programas escritos en Go lo activan por defecto, así que puede haberlos sin que nadie lo haya decidido.
  • La ventana de reinicio. Reiniciar el servidor de Odoo corta el servicio a los usuarios: elige el momento y avisa antes.

Medidas temporales, no definitivas

Si no puedes parchear todavía, puedes desactivar MPTCP (sysctl -w net.mptcp.enabled=0, de forma persistente y reiniciando los servicios) o aplicar la regla de nftables propuesta por Red Hat, que descarta los paquetes TCP sobre IPv4 con opciones IP. Ninguna sustituye al parche: el equipo de Go las considera frágiles y las reglas del host no protegen a los contenedores. En cualquier caso, la interfaz de gestión de Proxmox (puerto 8006) y SSH deberían ser accesibles solo desde una red de gestión o una VPN.

Cómo lo vemos en Binovo

Esta CVE recuerda algo que ya vimos con la vulnerabilidad crítica de PHP: lo difícil no es aplicar el parche, sino saber qué tienes y qué está realmente en ejecución. Recomendamos tres hábitos: un inventario de hosts y VM con su kernel en ejecución, una ventana de reinicio acordada y un responsable de vigilar los avisos de cada fabricante.

Si quieres que revisemos tu entorno, en Binovo trabajamos la administración de sistemas y somos partner de Proxmox, y también nos ocupamos del mantenimiento y soporte de Odoo. Cuéntanos tu caso y vemos por dónde empezar.

Fuentes

Transparencia: este artículo se ha elaborado con ayuda de inteligencia artificial a partir de las fuentes citadas y ha sido revisado y validado por el equipo de Binovo antes de publicarse.

About the author

Juanjo Bastarrika es CEO de Binovo, empresa de Oiartzun (Gipuzkoa) que desde 2008 implanta Odoo, soluciones de facturación Verifactu y TicketBAI, sistemas y desarrollo a medida, y del Grupo Binovo, al que pertenece Future AI, especializada en inteligencia artificial aplicada. Escribe sobre ERP, normativa fiscal e IA en la empresa desde la experiencia de implantación con clientes.

Leave a Reply