Tres fallos del kernel explotados en ataques reales: así está tu hosting con CloudLinux y KernelCare

Martes, Octubre 13, 2026

CloudLinux publicó el 7 de octubre, y actualizó el 12, el estado de tres fallos del kernel de Linux que la agencia de ciberseguridad de Estados Unidos (CISA) añadió el 18 de septiembre a su catálogo de vulnerabilidades que se están explotando de verdad. No son fallos teóricos: entrar en esa lista significa que hay ataques reales. En septiembre ya te contamos otras correcciones del kernel; estas tres son distintas y una de ellas tiene un exploit público.

Los tres fallos

  • CVE-2025-39964, en los sockets de cifrado (AF_ALG). Dos escrituras simultáneas sobre un socket de cifrado del kernel corrompen su estado interno. Existe un exploit público que convierte una cuenta normal en root. Es el más grave de los tres para un servidor compartido, y no tiene atajo: el código va dentro del kernel, así que bloquear el módulo no sirve. Solo lo arregla el kernel corregido o un parche en vivo.
  • CVE-2026-53266, en el cortafuegos de puentes de red (ebtables). Una regla de traducción de direcciones que reescribe paquetes ARP puede escribir fuera de su espacio de memoria, y de ahí corromper el sistema o escalar privilegios. Hace falta una configuración concreta de puentes de red, y en CloudLinux 9 el código está presente pero, según el fabricante, no es alcanzable con la configuración por defecto.
  • CVE-2025-39682, en el TLS del kernel. Un registro TLS de longitud cero se salta una comprobación y puede filtrar memoria del kernel o tumbar el sistema. Solo afecta si una conexión usa el TLS integrado en el kernel, algo que CloudLinux describe como poco habitual en servidores de hosting.

Cómo está nuestro hosting compartido

Lo comprobamos el 13 de octubre en el servidor de hosting compartido. Funciona con CloudLinux 9.8 y KernelCare, que parchea el kernel en caliente, sin reiniciar la máquina ni cortar tus webs.

  • CVE-2025-39964 y CVE-2026-53266: corregidos. El parche de KernelCare aplicado en el servidor se construyó el 8 de octubre e incluye los dos. Se aplicó sin reinicio. Cuando CloudLinux publicó su aviso, el parche del primero para la versión 9 todavía figuraba en preparación; a nuestro servidor ya ha llegado.
  • CVE-2025-39682: en seguimiento. CloudLinux indica que el kernel actual de la versión 9 ya trae la corrección y que hay parche en vivo, pero este fallo no aparece en la lista de parches de KernelCare de nuestro servidor. Hasta confirmarlo no te lo damos por cerrado, y lo seguimos. Recuerda que solo es explotable si se usa TLS en el kernel.

Tú no tienes que hacer nada en tu cuenta de hosting: kernel, parches y reinicios son parte del mantenimiento de la plataforma. Además, CloudLinux aísla cada cuenta en su propio entorno con límites de recursos, lo que pone más difícil que un problema en una web ajena llegue a la tuya. Si quieres ver cómo va tu cuenta de recursos, lo tienes en Cómo ver el consumo de recursos de tu hosting.

Si administras tu propio servidor con CloudLinux

  1. Si usas KernelCare, comprueba los tres de una vez: kcarectl --patch-info | grep -E 'CVE-2025-39964|CVE-2026-53266|CVE-2025-39682'. Sin KernelCare, compara la salida de uname -r con la versión corregida que da CloudLinux para tu rama.
  2. Para el fallo de cifrado no hay mitigación: actualiza el kernel o aplica el parche en vivo.
  3. Para el de los puentes de red, si no puedes parchear hoy, mira /proc/sys/user/max_user_namespaces. Con 0, una cuenta normal no llega al fallo. Ponerlo a 0 lo cierra, pero también deja sin contenedores sin root y funciones parecidas: no lo hagas a ciegas en una máquina con Docker.
  4. El estado cambia por ramas (7, 7h, 8, 9, 10 y las LTS): consulta la tabla del aviso para la tuya.

Si prefieres no tener que vigilar estas cosas, el hosting web te las quita de encima. Y si necesitas un servidor propio pero que lo mantengamos nosotros, mira la diferencia entre VPS administrado y no administrado.

Fuente: Aviso de CloudLinux sobre CVE-2025-39964, CVE-2026-53266 y CVE-2025-39682