CVE-2026-98276 es una vulnerabilidad de tipo use-after-free en el código de sockets UDP del kernel de Linux que, según CloudLinux, puede permitir a cualquier usuario local provocar la caída del kernel o elevar privilegios hasta root. Los ingenieros de CloudLinux reprodujeron ambos impactos y reportan que el 4 de noviembre un exploit provocó repetidos reinicios en un servidor con CloudLinux 8.
Qué cambia y a quién afecta
La falla reside en la función del kernel que responde a las solicitudes SIOCGSTAMP y SIOCGSTAMPNS —peticiones que piden la hora de recepción de un paquete en un socket—. Al ejecutar esa petición por primera vez, el kernel marca la estructura del socket sin tomar su cerrojo (lock). Si, al mismo tiempo, el mismo programa llama a bind() sobre ese socket UDP, las dos operaciones pueden interferir y borrar una bandera crítica (SOCK_RCU_FREE) que indica al kernel que espere antes de liberar la estructura. Sin la bandera, el socket puede liberarse mientras aún se está usando, provocando un use-after-free.
Todo usuario que pueda ejecutar programas en el servidor —por ejemplo, cuentas de hosting con acceso para correr procesos, cron jobs o aplicaciones que lancen binarios— alcanza el código vulnerable. Un firewall de red no bloquea este ataque porque se produce por llamadas del propio proceso al kernel, no por tráfico externo. CloudLinux señala que SELinux podría mitigar el riesgo si bloquea esas llamadas, pero añade que cPanel & WHM requiere SELinux desactivado en muchas instalaciones.
Parche, livepatch y estado por versiones
CloudLinux ofrece dos vías de mitigación: actualizar el kernel con un paquete corregido o aplicar un livepatch (KernelCare) que parchea el kernel en memoria sin necesitar reinicio.
- CloudLinux 7, 7h, 8, 8 LTS, 9, 9 LTS y 10 están listadas como afectadas; CloudLinux verifica aún la edición para Ubuntu 22.04.
- CloudLinux ha publicado un kernel fijo para CloudLinux 7h y CloudLinux 8 (versión indicada por CloudLinux en su aviso). El despliegue se está haciendo por fases; los servidores recibirán el kernel corregido cuando la actualización llegue a su rollout, o pueden instalarlo manualmente siguiendo las instrucciones del proveedor.
- Para CloudLinux 8 existe además un livepatch de KernelCare publicado en el feed principal; los servidores suscritos lo aplican en su ciclo de actualización o se puede forzar su instalación sin reinicio.
- Las versiones LTS de CloudLinux 8 y 9 ya incluyen el arreglo en builds etiquetados como els17 o posteriores.
- CloudLinux informa que KernelCare para CloudLinux 9 y 10 está en preparación; no hay livepatch para CloudLinux 7/7h.
- AlmaLinux ha adelantado kernels corregidos en su repositorio de pruebas para RHEL 9 y 10; Red Hat aún no había publicado un parche en el momento del aviso.
Qué deben hacer los administradores
CloudLinux recomienda a los administradores aplicar la corrección tan pronto como sea posible. Las opciones prácticas son:
- Instalar el kernel corregido desde los repositorios de CloudLinux cuando esté disponible para la versión del servidor y reiniciar para aplicar el cambio.
- Si no se puede planificar reinicios inmediatos, suscribirse a KernelCare y aplicar el livepatch (disponible ya para CloudLinux 8) para parchear el kernel en caliente sin downtime.
- Mientras no se aplique la corrección, reducir el riesgo limitando o suspendiendo cuentas que tengan capacidad de ejecutar programas (acceso shell, cron jobs, aplicaciones que arranquen procesos). CloudLinux aclara que esto disminuye el riesgo pero no lo elimina.
- Revisar registros de kernel en reinicios recientes (journalctl con boots anteriores) en busca de trazas de crash repetidas que coincidan con el exploit observado, y auditar qué cuentas o procesos se ejecutaban en esos momentos.
Impacto práctico
Si un atacante desde una cuenta de hosting o una web comprometida explota este fallo, puede provocar que el kernel se bloquee y todo el servidor se reinicie, dejando todas las webs y servicios offline mientras se repita el ataque. Además, en escenarios reproducidos por los ingenieros, el exploit puede otorgar root, lo que permitiría acceso total a sitios, correos y bases de datos del servidor.
Detalles técnicos del arreglo
El arreglo upstream consiste en tomar el cerrojo del socket en la primera llamada a la función afectada (sock_gettstamp()), garantizando que la bandera de la estructura se establezca de forma segura y evitando la condición de carrera que conducía al use-after-free.
Si no puede aplicar inmediatamente el parche, priorice medidas que reduzcan la capacidad de cuentas no confiables para ejecutar código. Planifique la actualización del kernel o la implantación de KernelCare lo antes posible y supervise los reinicios inesperados en sus servidores.
Lee también:
- Japón lanza paquete de emergencia de ciberseguridad con equipos de rescate y uso de IA
- Financiación de más de €1M impulsa certificados post-cuánticos en Let’s Encrypt
Fuente: CloudLinux
