La vulnerabilidad CVE-2026-98276 se corrigió en el código fuente original. A continuación, un servidor se bloqueó 12 veces.

Principales conclusiones

• La vulnerabilidad CVE-2026-98276 permite a un usuario local sin privilegios provocar una carrera de llamadas a sockets para bloquear el núcleo o obtener privilegios de root.
• Un exploit que provocaba el bloqueo de un servidor en 12 ocasiones ahora permite obtener privilegios de root en EL 8, 9 y 10.
• Red Hat no dispone de un kernel específico para RHEL 7, 8, 9 ni 10, y no indica ninguna medida de mitigación.
• Ya están disponibles los parches de KernelCare que no requieren reinicio para RHEL, AlmaLinux y CloudLinux 8 y 9, así como para Debian 12 y 13.

La versión resumida

Ir a la versión completa ↓

Qué ocurrió: El 6 de octubre de 2026, el equipo CVE del núcleo CVE-2026-98276 publicado, un error de «uso tras liberación» en los sockets UDP provocado por una carrera entre bind() y sock_gettstamp(), el controlador que indica a un programa cuándo ha llegado el último paquete de un socket. Cualquier usuario local que pueda abrir un socket UDP puede activarlo, pero no es accesible a través de la red. El 4 de noviembre, se utilizó un exploit operativo contra un servidor CloudLinux 8 y se estrelló 12 veces. Ir a esta sección → (Cómo se desarrolló el ataque en un servidor real) . Desde entonces, TuxCare ha creado un exploit de root operativo a partir del código recuperado de ese servidor.

A quién afecta: cualquier núcleo que no haya incorporado la corrección, lo que sigue afectando a muchos sistemas de producción. Esto incluye RHEL 7, 8, 9 y 10, así como las versiones recompiladas que utilizan el núcleo de Red Hat, entre las que se encuentran CloudLinux 8, 9 y 10. El alojamiento compartido es el punto débil, ya que las cuentas de los clientes suelen ejecutar su propio código en un núcleo compartido por todos. Ir a esta sección →

Situación actual:No se trata de una vulnerabilidad de día cero. La corrección ya estaba disponible en el código fuente original y en las ramas estables de este antes de que nadie informara de ningún ataque, y no se ha hecho público ningún código de explotación. TuxCare ha confirmado ahora la escalada de privilegios en EL 8, 9 y 10, incluido el último kernel de AlmaLinux 8, por lo que hay que tratarla como un acceso de root local en esos sistemas. En EL 7, la evaluación de TuxCare indica que solo se produce un bloqueo del sistema. Debian ha corregido los núcleos; Ubuntu, Oracle y Amazon han corregido algunos; y Red Hat no ha publicado ninguna corrección para ninguna versión de EL ni ha dado una fecha. Los parches sin reinicio de KernelCare están en producción para RHEL, AlmaLinux y CloudLinux 8 y 9, y EL 10 se encuentra en la rama de pruebas. Ir a esta sección →

Qué hacer hoy: No hay ningún parámetro sysctl que se pueda activar ni ninguna regla de cortafuegos que sirva de ayuda, por lo que aplicar el parche es la única solución real. En RHEL, AlmaLinux y CloudLinux 8 y 9, además de Debian 12 y 13, los usuarios de KernelCare pueden descargar el parche ahora mismo:

kcarectl --update

A continuación, compruébalo con kcarectl --patch-info | grep 'CVE-2026-98276'. En EL 10, que incluye CloudLinux 10, el parche se encuentra por ahora en el canal de pruebas, así que añade –prefix test al comando de actualización. Hasta que el parche esté disponible, restringe o suspende las cuentas locales en las que no confíes. Ir a esta sección →

Los fallos locales de denegación de servicio suelen quedar relegados a un segundo plano. El atacante necesita un punto de acceso en el equipo, el resultado habitual es un fallo del sistema y un reinicio, y la mayoría de las flotas tienen problemas más graves que resolver. CVE-2026-98276 parecía inicialmente uno de esos casos, pero no se quedó ahí.

Alguien ya lo ha utilizado. El 4 de noviembre, Un servidor con CloudLinux 8 sufrió 12 caídas a partir de un exploit que funciona para este fallo, y con kernel.panic_on_oops = 1 Una vez configurado, cada fallo significaba un reinicio completo. Dos días después, TuxCare había obtenido acceso de root en AlmaLinux 8 mediante un exploit creado a partir del código recuperado de ese servidor, y la escalada de privilegios ya se ha comprobado en EL 8, 9 y 10. Y no hay nada que se pueda desactivar. El código vulnerable se encuentra detrás de una llamada ioctl con marca de tiempo que cualquier proceso puede invocar en cualquier socket UDP que abra.

Los núcleos de los proveedores también se están quedando atrás. La corrección ya estaba disponible en el código fuente antes de que se publicara el CVE el 6 de octubre; Debian lanzó núcleos corregidos hace semanas, y Red Hat sigue indicando que las versiones de RHEL 7 a 10 se ven afectadas, sin ofrecer un núcleo corregido ni una fecha.

Cómo una consulta de marca de tiempo libera un socket activo

SIOCGSTAMP y SIOCGSTAMPNS, además de la _NEW Las versiones que utilizan los núcleos más recientes para el tiempo de 64 bits son ioctls antiguos y poco sofisticados. Un programa llama a uno de ellos en un socket para preguntar cuándo llegó el último paquete, y el núcleo responde a través de sock_gettstamp() en net/core/sock.c. La primera vez que se consulta un socket, el controlador también activa el sellado de tiempo configurando el SOCK_TIMESTAMP un poco de sk->sk_flags.

El problema es que lo hace sin sujetar el cierre de la llave de vaso, y el ayudante que está debajo utiliza __set_bit(), que no es una operación atómica. La CPU lee la palabra de indicadores completa, realiza una operación OR con un bit y vuelve a escribir la palabra completa. Si, entre la lectura y la escritura, algo más modifica otro bit de esa palabra, ese cambio se pierde.

Ese otro escritor es bind(). Al vincular un socket UDP, udp_lib_get_port() conjuntos SOCK_RCU_FREE y añade el socket a la tabla hash, donde la ruta de recepción UDP puede encontrarlo sin necesidad de bloquearlo. SOCK_RCU_FREE Es la garantía que ofrece el núcleo a esos lectores sin bloqueo. Cuando se cierra el socket, el núcleo espera un periodo de gracia de RCU antes de liberarlo, para que cualquiera que aún lo esté consultando pueda terminar.

Si se ejecutan ambos en procesadores diferentes, la sincronización puede fallar. La llamada ioctl lee los indicadores justo antes de bind() conjuntos SOCK_RCU_FREE, y luego vuelve a escribir su copia obsoleta una vez que el socket ya figura en la tabla. El indicador ha desaparecido, pero el socket sigue siendo visible para los lectores sin bloqueo, y nada en el núcleo sabe que se ha incumplido la promesa. Si se cierra mientras un paquete está en tránsito, el núcleo libera la memoria inmediatamente, aunque la ruta de recepción aún la esté utilizando. Eso es lo que se conoce como «uso después de la liberación» (use-after-free).

En solución de Eric Dumazet introduce el cierre de rosca sock_gettstamp(), pero solo cuando SOCK_TIMESTAMP de hecho hay que configurarlo, para que la ruta común no se bloquee. El Registro CVE atribuye el reportaje a Jungwoo Lee y Wongi Lee, y el KASAN indica que las citas proceden de un programa de pruebas que los periodistas denominaron exploit.

En ese mismo mensaje de confirmación se señala que sk_set_memalloc() y sk_clear_memalloc() cambiar también sk_flags sin el bloqueo. Sus llamadores (nbd, iSCSI, NVMe sobre TCP, sunrpc y WireGuard) necesitan una auditoría previa, por lo que el equipo de desarrollo principal tiene previsto lanzar un parche independiente. Se trata de una corrección independiente que se abordará en otro momento y que no forma parte de este CVE.

Cualquier núcleo que no incorpore la corrección sigue teniendo ese problema, y muchos núcleos empresariales que están en producción aún no la han incorporado.

El servidor atacado ejecutaba un núcleo de CloudLinux 8, y cada fallo dejaba el mismo rastro en el registro del núcleo. Primero aparecían advertencias en las líneas 153 y 156 de net/ipv4/af_inet.c, en el interior inet_sock_destruct(), el código que cierra un socket. A continuación se produjo una desreferencia de un puntero NULL, ya fuera en udp_destruct_common() mientras el enchufe se cerraba o en __sk_mem_raise_allocated() llamado desde __udp_enqueue_schedule_skb() mientras se ponía en cola un paquete. Ambas situaciones son las que cabría esperar cuando la ruta de cierre y la ruta de recepción compiten por un socket que ya no existe.

El servidor tenía kernel.panic_on_oops = 1, que utilizan muchas configuraciones de alojamiento para que un kernel defectuoso se reinicie en lugar de seguir funcionando a duras penas. Eso hizo que cada «oops» provocara un reinicio: doce en total. Nunca se tuvo acceso de root en ese servidor, solo se produjeron los fallos, y no ha aparecido ningún código de explotación en la red.

Si un servidor se ha estado reiniciando sin motivo aparente, comprueba el registro del núcleo del arranque anterior en busca de esos nombres de funciones. Para ello es necesario disponer de un diario persistente:

journalctl -k -b -1 | grep -E 'inet_sock_destruct|udp_destruct_common|__sk_mem_raise_allocated|__udp_enqueue_schedule_skb'

Una coincidencia no es, por sí sola, prueba de un ataque, pero en un kernel sin parches es un buen motivo para comprobar quién había iniciado sesión y qué programas estaba ejecutando.

De «Crash Bug» a «Root Bug»

El equipo de CVE del núcleo califica el CVE-2026-98276 con un 7,8 (alto), con un vector de ataque local, baja complejidad de ataque, privilegios bajos y alto impacto en la confidencialidad, la integridad y la disponibilidad. Red Hat lo califica como «moderado» con un 7,0, y SUSE y Amazon también le otorgan un 7,0. La diferencia radica en la complejidad del ataque, que estos proveedores califican como alta porque el atacante tiene que ganar una carrera. Es un argumento válido sobre el papel, pero el incidente de CloudLinux 8 demuestra que esa carrera se puede ganar en un servidor de producción, una y otra vez.

La mayor discrepancia se daba entre la puntuación y las pruebas, y esa discrepancia se ha reducido. El vector 7.8 parte de la base de que un fallo de «uso tras liberación» (use-after-free) en un socket como este puede aprovecharse para la escalada de privilegios, y TuxCare lo ha conseguido. Su equipo obtuvo privilegios de root en AlmaLinux 8 con el kernel predeterminado, utilizando un exploit creado a partir del código recuperado del servidor atacado, y desde entonces ha confirmado la escalada de privilegios en EL 8, 9 y 10. Esto incluye el último kernel de AlmaLinux 8, el 4.18.0-553.184.1.el8_10. El exploit no es totalmente fiable, pero ha funcionado en varias ocasiones. En EL 7, la evaluación de TuxCare apunta únicamente a un fallo local. En el resto de la familia EL, hay que considerar esto como un acceso de root local y otorgarle mayor prioridad de la que sugiere la puntuación del proveedor para la versión 7.0.

CloudLinux 9 y 10 utilizan núcleos de AlmaLinux, por lo que siguen la línea de AlmaLinux. En Ubuntu, el estado depende de la variante del núcleo, así que comprueba el paquete que realmente utilizas en lugar del número de versión. Si compilas tus propios núcleos, cualquiera de las versiones estables mencionadas anteriormente incluye la corrección.

Las versiones anteriores cubiertas por el programa «Endless Lifecycle Support» (ELS) de TuxCare se encuentran en mejor estado de lo que cabría imaginar. Los núcleos ELS que incorporan esta corrección se distribuyeron entre el 14 y el 26 de octubre para CentOS 6, Oracle Linux 6, CentOS 8.5 y Ubuntu 20.04, junto con los núcleos de soporte ampliado para AlmaLinux 9.2 y 9.6.

La mayoría de los errores del núcleo vienen acompañados de algún ajuste que se puede modificar mientras se prepara el parche, como un módulo que se puede descargar o un parámetro sysctl que se puede cambiar. Este, sin embargo, no tiene nada de eso. sock_gettstamp() Se trata de código básico del socket, y no hay ningún sysctl ni opción de arranque que lo desactive. Cualquier usuario normal que pueda crear un socket UDP puede acceder a él, y en una instalación predeterminada eso incluye a todo el mundo.

Un cortafuegos no servirá de nada. El desencadenante son un par de llamadas al sistema en un socket que controla el atacante, y ninguna de ellas pasa por iptables ni por nftables.

Una política de SELinux podría bloquear las llamadas ioctl de marca de tiempo. Sin embargo, en CloudLinux, cPanel y WHM requieren que SELinux esté desactivado, por lo que esa opción queda descartada para muchos servidores de alojamiento.

Lo que queda es limitar quién puede ejecutar código en el servidor. En el alojamiento compartido, esto incluye el acceso a la línea de comandos, las tareas programadas (cron) y cualquier aplicación de los clientes que pueda ejecutar sus propios binarios. Restringe o suspende las cuentas en las que no confíes hasta que se haya aplicado el parche, y mantente atento a los reinicios inexplicables, teniendo en cuenta que es posible que solo te muestren los intentos fallidos. A continuación, aplica el parche.

El parche sin reinicio de KernelCare adapta la corrección del código fuente tal cual, aplicando el bloqueo de socket en torno a la actualización del indicador. Se trata de un pequeño cambio que no afecta a las estructuras de datos, lo que lo convierte en una opción ideal para un parche sin reinicio, y se está distribuyendo en toda la familia EL, mientras que Red Hat aún no dispone de un núcleo corregido para ninguna versión de EL. LibCare no interviene, ya que se trata de un error del núcleo.

EL 7 es la excepción. Según la evaluación de TuxCare, se trata de un fallo local sin escalada de privilegios, por lo que no hay planes de aplicar el parche antes que Red Hat. En todos los casos en los que el parche está en producción, los hosts con actualizaciones automáticas de KernelCare lo obtienen según su calendario habitual, o bien puedes descargarlo inmediatamente con el comando `kcarectl –update`. En EL 10, incluido CloudLinux 10, por ahora se encuentra en el canal de pruebas, así que utiliza kcarectl –update –prefix test. En cualquier caso, no es necesario reiniciar. A continuación, comprueba que se haya instalado correctamente:

kcarectl --patch-info | grep 'CVE-2026-98276'

Si no aparece nada en pantalla, significa que KernelCare no ha aplicado ningún parche para este CVE, por lo que debes comprobar si el servidor ya está ejecutando un kernel del proveedor que haya sido corregido antes de dar por hecho que está expuesto. El CVE Tracker de TuxCare muestra el estado de los parches que no requieren reinicio por distribución, a medida que va cambiando.

Consigue KernelCare hoy mismo →

Unas cuantas líneas de bloqueo y una larga espera

La corrección en el código fuente consta de unas pocas líneas, y los usuarios de RHEL siguen sin disponer de un kernel del proveedor que puedan instalar.

Según los criterios habituales, nadie debería haberse dado cuenta de este caso. La corrección se implementó antes de que se publicara el CVE, el CVE se publicó un mes antes de que se produjera ningún ataque y no hay ningún código de explotación disponible públicamente. Sobre el papel, un error que provoca un bloqueo local con una puntuación del proveedor de 7,0 no es motivo para saltarse la cola.

Entonces apareció un exploit funcional en un servidor de alojamiento en producción, mientras que los núcleos de la familia RHEL que utilizan muchos servidores de alojamiento aún no cuentan con ninguna corrección del fabricante. En dos días, ese mismo código de exploit se había convertido en un exploit de root. El alojamiento compartido es casi el peor escenario posible para un fallo local. Muchos clientes pueden ejecutar su propio código con una cuenta local, y basta con que uno de ellos bloquee el servidor o se haga con el control para que todos los demás usuarios se vean afectados.

Así que, si gestionas servidores multitenant, no clasifiques este problema como un ataque DoS local. En las versiones EL 8 a 10, se trata de un acceso root local. Revisa los registros en busca de la firma del fallo, refuerza la seguridad de las cuentas en las que no confíes y aplica la corrección, ya sea mediante un parche sin necesidad de reiniciar cuando esté disponible o reiniciando con un kernel corregido, si tu distribución dispone de uno.

Consigue KernelCare hoy mismo →

Cómo se desarrolló todo

Fuentes

Las fuentes principales de esta entrada son el anuncio de CVE del núcleo, el registro CVE y la corrección del desarrollador original, además de las páginas de los proveedores Red Hat (incluido su sistema de seguimiento de errores), Debian, Ubuntu, SUSE, Amazon y Oracle. También se citan el informe de incidentes de CloudLinux, la entrada del NVD, el registro de la OSV y los registros de lanzamiento de KernelCare y ELS de TuxCare a fecha de 9 de noviembre de 2026.