GhostLock: un escape de contenedor que rompe la premisa del sandbox de los agentes

¿De qué se trata?

El 8 de julio de 2026, Nebula Security divulgó GhostLock, un use-after-free en el código de mutex de tiempo real (rtmutex) del kernel de Linux, en la ruta de herencia de prioridad. Un usuario local sin privilegios puede explotarlo para obtener root — y, algo crucial para quien ejecute agentes de IA, funciona desde dentro de un contenedor para escapar hacia el host. El fallo se introdujo en 2011 (Linux 2.6.39) y permaneció sin detectar durante unos quince años, hasta que una herramienta de análisis automatizado lo sacó a la luz. Ya está corregido en la rama principal (commit 3bfdc63936dd, Linux 7.1) y las distribuciones comenzaron a publicar parches esa misma semana; AlmaLinux publicó su aviso el 9 de julio.

No lo cubrimos como una curiosidad de seguridad del kernel. Lo cubrimos porque el aislamiento por contenedor es la premisa que sostiene casi todos los sandboxes de ejecución de código de los agentes — la caja donde un agente de código ejecuta scripts generados, donde un agente con herramientas evalúa código no confiable, donde un runner de CI ejecuta una tarea escrita por una IA. GhostLock es una vía fiable y sin privilegios para salir de esa caja, y ya existe un exploit funcional público.

Cómo funciona

El fallo reside en kernel/locking/rtmutex.c, en la ruta de herencia de prioridad de los futex. Una función de limpieza (remove_waiter()) asume que el waiter que limpia siempre pertenece a la tarea en ejecución. En la ruta de requeue FUTEX_CMP_REQUEUE_PI, sin embargo, el kernel a veces debe deshacer operaciones en nombre de otro hilo dormido tras detectar un ciclo de bloqueo y revertir con -EDEADLK. Durante esa reversión borra el pi_blocked_on de la tarea equivocada, dejando un puntero colgante hacia memoria de pila del kernel ya liberada — un use-after-free de pila.

Para desencadenarlo, un atacante dispone tres futex y un conjunto de hilos coordinados en un interbloqueo por inversión de prioridad, y luego reocupa el marco de pila liberado con una estructura waiter falsificada. A partir de ahí, el informe público encadena una escritura restringida hasta lectura/escritura arbitraria del kernel, secuestra el flujo de control y termina como root. Nebula indica que el exploit es fiable al 97 % y se ejecuta en unos cinco segundos en su máquina de prueba, y señala que Google otorgó al equipo 92 337 $ mediante el programa kernelCTF. El único requisito previo es poder ejecutar llamadas de threading ordinarias como proceso local — sin capacidades especiales ni configuraciones inusuales. La exposición es amplia porque la ruta solo depende de CONFIG_FUTEX_PI, habilitado en prácticamente todos los kernels de distribución. Omitimos las primitivas de explotación; el mecanismo anterior procede íntegramente de la divulgación pública.

Por qué importa

Para una plataforma de agentes, «el atacante necesita un punto de apoyo local» no es la garantía que parece. El sentido mismo de un sandbox de ejecución de código es conceder deliberadamente un punto de apoyo local a código no confiable y confiar en la frontera del contenedor para mantenerlo ahí. Un agente de código víctima de una inyección de prompt, una skill maliciosa o una fixture de prueba aportada por un atacante que alcanza la ejecución de código dentro del contenedor ya está exactamente en la posición que GhostLock necesita. A partir de ahí, el escape contenedor-a-host convierte «el agente ejecutó algo que no debía dentro de su sandbox» en «el sandbox del agente ya no existe». En infraestructura compartida y multiinquilino — runtimes de agentes alojados, CI, backends de notebooks — eso significa pasar de la tarea de un inquilino al host, y potencialmente a todos los demás inquilinos que allí residan.

Dos apuntes de contexto refuerzan el argumento sin exagerarlo. Primero, GhostLock es la mitad de kernel de una cadena que Nebula llama IonStack: combinada con un fallo de escape de sandbox de navegador, un simple toque en un enlace malicioso se llevó hasta root en Android — recordatorio de que un fallo «solo local» se vuelve remoto al injertarse en una etapa anterior. Segundo, el fallo lo encontró una herramienta de análisis impulsada por IA rastreando maquinaria antigua del kernel, dentro de una serie de 2026 de hallazgos similares de escalada de privilegios en futex/bloqueos. Los límites honestos: se valora en 7,8 (alta, no crítica) precisamente porque exige ejecución local, no se conoce explotación en la naturaleza hasta la fecha y existen kernels parcheados. Lo que acelera el calendario es la disponibilidad pública del exploit.

Defensas

La lección para los operadores de agentes es que la frontera del contenedor es un control que puede fallar, así que nunca debería ser lo único entre la ejecución no confiable y el host:

• Parchee el kernel como prioridad en cada host que ejecute cargas de agentes. Instale el kernel actual de su distribución, no solo el primer build parcheado — el arreglo inicial introdujo un fallo de crash aparte (ver Status), por lo que los primeros builds pueden estar incompletos. Priorice los runtimes de agentes multiinquilino, los runners de CI y los backends de código/notebooks.
• No trate a los contenedores como una frontera de seguridad por sí solos. Coloque una segunda capa bajo la ejecución de código de los agentes — un sandbox basado en virtualización (microVM / estilo gVisor) o una VM dedicada y desechable por cada tarea no confiable — para que un escape del kernel no alcance de inmediato un host compartido.
• Minimice lo que un sandbox comprometido puede alcanzar. No otorgue a los entornos de ejecución de agentes credenciales de nube ambientales, ni montajes del host, ni ruta de red lateral; asuma que el sandbox puede ser vulnerado y acote el radio de impacto en consecuencia.
• Endurezca la configuración de build. RANDOMIZE_KSTACK_OFFSET y STATIC_USERMODE_HELPER dificultan este exploit concreto. Son mitigaciones, no arreglos, y no sustituyen al parche.
• Vigile la escalada de privilegios, no solo las anomalías de prompt. La detección en ejecución en los hosts de agentes debe atender a la escalada a nivel de kernel y a transiciones inesperadas a root, no únicamente a las señales del modelo — el paso dañino ocurre aquí muy por debajo del LLM.

Status

Elemento	Detalle
Nombre	GhostLock
Referencia	CVE-2026-43499 (NVD) — CVSS 7,8 (alta)
Tipo	Use-after-free de pila, rtmutex / herencia de prioridad de futex (FUTEX_CMP_REQUEUE_PI)
Impacto	Root local sin privilegios y escape contenedor-a-host
Introducida	Linux 2.6.39 (2011); ~15 años sin detectar
Corregida	Commit principal 3bfdc63936dd, Linux 7.1; backports de distribuciones desde la semana del 7 jul. 2026
Descubrimiento	Nebula Security, mediante la herramienta de análisis impulsada por IA «VEGA»; reportada a security@kernel.org
Exploit	PoC público; fiabilidad ~97 %, ~5 s; recompensa de Google kernelCTF de 92 337 $
Salvedad	Se recomienda un parche de seguimiento para una regresión de crash aparte (CVE-2026-53166) introducida por el parche inicial
En la naturaleza	Sin explotación conocida a la fecha de divulgación (8 jul. 2026)