CloudLinux ha publicado un resumen del impacto y las actualizaciones disponibles tras la revelación pública del conjunto de seis fallos de escalada de privilegios locales en el kernel Linux denominado «Infinity Core» (varios CVE, entre ellos CVE-2026-98260 y CVE-2026-98256). La nota, actualizada el 21 de octubre de 2026, detalla qué ramas de CloudLinux están afectadas, qué parches ya se han distribuido y qué medidas temporales existen para administradores de servidores.
Qué cambios y a quién afecta
Los errores afectan componentes centrales del kernel usados por cualquier proceso (timers POSIX, señales, futexes, mincore(), entre otros), por lo que basta una cuenta local sin privilegios para intentar explotarlos en un servidor compartido. CloudLinux identifica exposición en:
- CloudLinux 9: afectado; kernels corregidos ya publicados.
- CloudLinux 10: afectado; kernels corregidos ya publicados y también contiene el fallo de señales.
- CloudLinux for Ubuntu 22.04: afectado por el fallo del timer; la corrección depende de Ubuntu.
- CloudLinux 8 LTS y 9 LTS: el análisis de código muestra presencia del código vulnerable del timer, pero no se ha reproducido la explotación; están pendientes parches de TuxCare/ELS.
- CloudLinux 7, 7h y ramas con kernel 4.18/3.10: aún están en análisis para el fallo del timer; por ahora no se ha confirmado exposición para el resto de los fallos.
Parches y mitigaciones disponibles
CloudLinux anuncia kernels corregidos para CloudLinux 9 y 10: los paquetes citados en el aviso (por ejemplo, 5.14.0-687.59.1.el9_8 para CL9 y 6.12.0-211.67.1.el10_2 para CL10) están publicados —o versiones posteriores— y contienen la reparación del fallo de timer; además, la corrección del fallo de futex ya se distribuyó en versiones anteriores de esos flujos. Para CloudLinux for Ubuntu, la corrección llegará vía los canales de seguridad de Ubuntu.
Como alternativa sin reinicio, CloudLinux prepara un livepatch de KernelCare para el fallo del timer (comenzando por CloudLinux 9 y 10 y para los kernels de Ubuntu afectados). El livepatch del futex ya está disponible. Hasta que llegue el livepatch o se instale un kernel fijo, CloudLinux indica que no existe una mitigación fiable basada en sysctl, blacklisting de módulos, namespaces sin privilegios o en CageFS: esas medidas no evitan las llamadas al sistema implicadas.
Qué debe hacer el administrador
- Verificar la versión de kernel en los servidores: compare uname -r con las versiones corregidas comunicadas por CloudLinux (o instala actualizaciones más recientes).
- Si el kernel fijo está disponible, planificar un reinicio tras la actualización del kernel para aplicar la corrección de forma definitiva.
- Si no puede reiniciar de inmediato, solicitar y aplicar el livepatch de KernelCare cuando esté disponible (kcarectl –update para pedir parches bajo demanda).
- Priorizar servidores compartidos donde usuarios tienen shells o acceso SSH: allí el riesgo es mayor porque un sitio comprometido puede intentar usar un exploit local para escalar a root en el host.
- Reforzar las capas de aplicación: parchear CMS, plugins y aplicaciones web para evitar que un atacante alcance una cuenta local explotable.
Contexto técnico y riesgo
La divulgación pública de los seis fallos incluyó código de prueba y, en algunas distribuciones, exploits de root. En CloudLinux la principal preocupación es el bug del timer POSIX (CVE-2026-98260), aunque también se han observado reproducciones de bloqueo del kernel; TuxCare analizó los fallos frente a kernels soportados y no reportó explotación activa en la naturaleza hasta la fecha citada. La presencia real de cada fallo en un flujo de kernel concreto depende de la base de código y de backports, por lo que CloudLinux advierte que no se debe inferir seguridad solo por el número base del kernel.
En resumen: aplique cuanto antes los kernels corregidos o los livepatches cuando estén disponibles, priorice hosts compartidos con acceso por cuenta de usuario y mantenga actualizadas las aplicaciones web para reducir la posibilidad de que una intrusión local derive en un compromiso del servidor.
Lee también:
- BeamFS, un sistema de archivos experimental para detectar y reparar datos, propuesto para el kernel Linux
- HPE llevará ordenador para IA y HPC a la Luna con el rover FLIP de Astrolab
Fuente: CloudLinux
