Ciberseguridad · Aviso

Kernel de Linux · Escalada local a root por uso de memoria liberada

GhostLock (CVE-2026-43499) permite a un usuario local sin privilegios hacerse con el control de un sistema Linux sin actualizar; hay parches desde la primavera y exploit público, pero no consta su uso en ataques reales.

Publicado 30 octubre 2026 Lectura 10 min Ref. CVE-2026-43499, CVE-2026-53163 CVSS 7.8 (CNA del kernel de Linux (kernel.org), recogido en NVD para CVE-2026-43499; Red Hat, SUSE y Ubuntu también indican 7,8)

Resumen

GhostLock es un fallo de gestión de memoria en el kernel de Linux, presente desde la versión 2.6.39 (2011), que permite a quien ya puede ejecutar código en la máquina obtener privilegios de administrador (root). No se puede explotar por sí solo a distancia. Sus descubridores, Nebula Security, publicaron el código de explotación en julio de 2026 y afirman que también permite salir de un contenedor; esto último no consta verificado de forma independiente. No figura en el catálogo KEV de CISA ni consta explotación real. La solución es instalar el kernel corregido de cada distribución y reiniciar.

Materias: Vulnerabilidades, Linux, Contenedores, Escalada de privilegios, Sistemas industriales

Un error de programación que llevaba unos quince años en el kernel de Linux, el núcleo del sistema operativo, permite a un usuario sin permisos convertirse en root, el administrador con control total de la máquina. La vulnerabilidad, bautizada GhostLock y registrada como CVE-2026-43499, tiene parches y exploit públicos. Es seria en servidores compartidos y plataformas de contenedores, pero requiere poder ejecutar código previamente en el sistema y, a fecha de este aviso, no consta su uso en ataques reales.

Descripción

Qué es

CVE-2026-43499 es una vulnerabilidad de tipo use-after-free (CWE-416): el programa sigue usando una zona de memoria que ya no es válida, lo que un atacante puede aprovechar para alterar el comportamiento del sistema. Está en rtmutex, el código del kernel que ordena el acceso de los hilos de ejecución a recursos compartidos, concretamente en la función remove_waiter().

El CVSS, la escala de gravedad de 0 a 10, es de 7,8 (alto) según el CNA del kernel, la entidad que asigna el identificador. El vector AV:L/AC:L/PR:L/UI:N significa: ataque local, de baja complejidad, con pocos privilegios y sin intervención de la víctima. Red Hat clasifica el fallo como CWE-825 (uso de un puntero caducado), una descripción compatible con la anterior.

A quién afecta de verdad

Quedan expuestos, en primer lugar, los sistemas donde personas o programas poco fiables pueden ejecutar código: servidores multiusuario, nodos de contenedores que alojan cargas de terceros y ejecutores de integración continua (CI, las máquinas que compilan y prueban código automáticamente). En un equipo o servidor de uso exclusivo, el fallo importa sobre todo como segundo paso: un intruso que ya hubiera entrado por otra vía podría usarlo para ampliar su control.

Versiones afectadas

Kernel oficial: desde la versión 2.6.39 hasta las anteriores a 5.10.261, 5.15.212, 6.1.175, 6.6.140, 6.12.86, 6.18.27 y 7.0.4. La corrección se integró en la rama principal para Linux 7.1.
Red Hat: RHEL 6, 7, 8, 9 y 10, y productos que dependen de su kernel, como CoreOS, OpenShift, OpenStack Platform y Red Hat Virtualization.
Otras distribuciones: Debian, Ubuntu y SUSE tienen entradas propias con paquetes corregidos. Ubuntu 26.10 figura como no afectada.
Equipos industriales Siemens: el subsistema GNU/Linux adicional de los SIMATIC y SIPLUS S7-1500 CPU 1518(F)-4 PN/DP MFP. El registro CVE añade el SIMATIC S7-1500 TM MFP.

Las distribuciones suelen trasladar correcciones a versiones antiguas (backport), de modo que el número de versión no basta para saber si un kernel está corregido: hay que consultar el aviso de cada distribución.

Mecánica

El fallo

Un futex es un mecanismo con el que los programas coordinan sus hilos. Su variante con herencia de prioridad evita que una tarea importante quede bloqueada por otra menos importante. En esa variante, el kernel puede mover un hilo en espera de una cola a otra mediante futex_requeue(), operación que ejecuta un hilo distinto del que espera.

Si la operación falla porque detecta un bloqueo circular, el kernel la revierte llamando a remove_waiter(). Esa función da por hecho que el hilo actual (current) es el que espera, cosa que aquí no es cierta. Según la descripción oficial, hay tres consecuencias:

El hilo se retira de la cola sin tomar el cerrojo (pi_lock) que debería protegerlo.
No se limpia el dato pi_blocked_on del hilo afectado, que queda como un puntero colgante: una referencia a memoria que ya no es válida. Según Nebula, apunta a la pila, la memoria temporal del propio hilo en el kernel.
El ajuste de prioridades se realiza sobre la tarea equivocada.

La corrección consiste en usar el hilo correcto (waiter::task) en estas operaciones.

Requisitos del ataque

Poder ejecutar código en el sistema, aunque sea con una cuenta sin privilegios o desde un proceso dentro de un contenedor.
Un kernel compilado con CONFIG_FUTEX_PI=y, la opción habitual en los kernels de uso general. Según Nebula no hacen falta capacidades especiales ni espacios de nombres de usuario (user namespaces).

Lo confirmado y lo que solo afirma una parte

Confirmado por fuentes oficiales: la existencia y la naturaleza del fallo, las versiones y los parches. Red Hat reconoce el riesgo de escalada de privilegios y de denegación de servicio (dejar el sistema inoperativo).
Afirmado por Nebula Security: una estabilidad del 97 % y la obtención del resultado en unos 5 segundos en kernelCTF, el programa de recompensas de Google. El objetivo fue un kernel 6.12.80 en x86. Google concedió 92.337 dólares, también según Nebula. Estas cifras describen una prueba concreta y no predicen el resultado en cualquier sistema.
Escape de contenedores: un contenedor es un entorno aislado que comparte el kernel con la máquina anfitriona, de ahí que un fallo del kernel pueda romper ese aislamiento. Nebula lo presenta como resultado de su exploit, pero el informe no detalla la configuración del contenedor. No he encontrado una confirmación independiente, ni la mención en el boletín de Red Hat consultado, así que no debe darse por hecho en toda configuración.
Alcance real del código público: las fuentes no coinciden. Nebula describe un exploit y una prueba de concepto (PoC) publicados, y su repositorio tiene carpetas para ambos. El aviso de OSG, en cambio, describe un PoC específico de Android que solo provoca un bloqueo. Un administrador de la Universidad de Hamburgo reprodujo con el PoC un cuelgue en Ubuntu con el kernel 7.0.0-14. No he comprobado el funcionamiento del exploit.

Respuesta del creador

Cronología

18 de abril de 2026: Nebula Security comunica el fallo a los responsables de seguridad del kernel.
20-21 de abril: se publica la corrección (commit 3bfdc63936dd). Nebula da el día 20; el mensaje en oss-security, el 21.
Principios de mayo: la corrección llega a las ramas estables.
21 de mayo: se publica CVE-2026-43499.
7 de julio: Nebula publica su análisis técnico, y al día siguiente el asunto llega a la lista oss-security.

Fabricantes y autoridades

Mantenedores del kernel: corrigieron el fallo en la rama principal y en las estables.
Red Hat: le asigna impacto «Important», publicó el boletín RHSB-2026-010 y afirma que aplicar el kernel actualizado es la única corrección completa.
Ubuntu y SUSE: lo clasifican como prioridad alta e importante, respectivamente, y publican paquetes corregidos.
Siemens: sus avisos SSA-019113 y SSA-457936 indican que aún no hay solución para los equipos afectados y que prepara correcciones, sin fecha.
CISA (agencia de ciberseguridad de EE. UU.): en la consulta del 30 de octubre de 2026, el fallo no aparece en su catálogo KEV de vulnerabilidades explotadas. Su valoración técnica registra «poc»: existe prueba de concepto, sin constancia de explotación.
INCIBE-CERT: mantiene una ficha técnica con CVSS 7,8 y CWE-416. No he localizado un aviso específico con recomendaciones propias.

Ninguna de las fuentes consultadas informa de ataques reales que hayan usado este fallo.

Parches y mitigaciones

Una corrección en dos pasos

El primer parche cerró GhostLock, pero introdujo otro problema: en determinados casos, un usuario local podía provocar una caída del sistema por un acceso a un puntero nulo. Ese segundo fallo no da privilegios: tiene un CVSS de 5,5 según NVD, con impacto solo en la disponibilidad. Se corrigió en el commit 40a25d59e85b y consta como CVE-2026-53163.

Algunas noticias, y el propio informe de Nebula, citan el identificador CVE-2026-53166 para este problema. Ese registro figura hoy como rechazado por el CNA del kernel, sin motivo publicado. Su descripción previa en bases de terceros apunta al mismo tipo de fallo, pero no he podido confirmar la relación entre ambos identificadores.

Versiones del kernel oficial

6.1: GhostLock corregido en 6.1.175; ambos fallos, en 6.1.177.
6.6: GhostLock corregido en 6.6.140; ambos, en 6.6.144.
6.12: GhostLock corregido en 6.12.86; ambos, en 6.12.95.
6.18: GhostLock corregido en 6.18.27; ambos, en 6.18.36.
7.0: GhostLock corregido en 7.0.4; ambos, en 7.0.13.
5.10 y 5.15: GhostLock corregido en 5.10.261 y 5.15.212. El registro de CVE-2026-53163 no publica rangos de versión para estas ramas, así que conviene instalar la última versión disponible.

Paquetes de algunas distribuciones

Estas versiones corrigen CVE-2026-43499. No he comprobado en cada caso la inclusión del segundo parche: consulte también la entrada de CVE-2026-53163 de su distribución.

Ubuntu: 26.04, 7.0.0-27.27; 24.04, 6.8.0-136.136; 22.04, 5.15.0-187.197; 20.04, 5.4.0-234.254. Las variantes para nube tienen numeración propia.
Debian: repositorio de seguridad de trixie, 6.12.113-1; de bookworm, 6.1.190-1. Ambas superan la numeración oficial que incluye los dos parches.
SUSE: SLES 15 SP7, 6.4.0-150700.53.60.1; SLES 16.0, 6.12.0-160000.34.1.
Red Hat: según su boletín, hay erratas disponibles; consulte el paquete exacto para su versión.

Qué hacer ya

Inventariar los sistemas Linux y empezar por los servidores multiusuario, los nodos de contenedores, los ejecutores de CI y los que ejecutan código de terceros.
Instalar el kernel corregido de la distribución y reiniciar: hasta entonces sigue funcionando el kernel anterior. Después, comprobar la versión activa con uname -r.
Revisar las imágenes de nodos en servicios gestionados de Kubernetes y equipos con Linux integrado, que pueden depender del calendario de su proveedor.
Limitar entretanto quién puede ejecutar código en los sistemas pendientes de actualizar.

Mitigaciones provisionales

Red Hat y el mensaje en oss-security coinciden en que no hay un módulo ni un ajuste que elimine el fallo. Las medidas siguientes solo reducen el riesgo:

Filtro seccomp en contenedores: seccomp limita las llamadas al kernel que puede hacer un proceso. Huawei Cloud propone bloquear las operaciones FUTEX_WAIT_REQUEUE_PI y FUTEX_CMP_REQUEUE_PI, y advierte de que debe validarse antes en un entorno de pruebas.
RANDOMIZE_KSTACK_OFFSET: esta opción del kernel añade aleatoriedad a la pila y, según Nebula, obliga a acertar un desplazamiento de unos 5 bits para usar la técnica publicada. Dificulta el ataque, no lo impide.
STATIC_USERMODE_HELPER: según Nebula, cierra una vía concreta de su exploit, aunque la idea puede trasladarse a otros parámetros del sistema.
Exposición reducida en algunos entornos: Red Hat indica que es menor donde no se usan planificación en tiempo real ni futex con herencia de prioridad, pero el código afectado sigue presente. No debe tratarse como motivo para no actualizar.
Equipos Siemens: a falta de parche, el fabricante recomienda ejecutar solo aplicaciones de fuentes fiables, limitar el acceso a la consola del subsistema Linux a personal de confianza y proteger el acceso de red.

Apunte para responsables de cumplimiento

La mera existencia de esta vulnerabilidad no constituye una brecha de datos personales ni, por sí sola, activa la notificación del artículo 33 del RGPD. Sí es relevante para el deber de mantener medidas de seguridad adecuadas (artículo 32), por lo que conviene documentar la evaluación y la actualización. Si se detectara un acceso no autorizado a datos personales, habría que valorar la notificación a la autoridad de control en el plazo de 72 horas.