Una escritura de apenas 16 bytes parece demasiado pequeña para comprometer un sistema Linux. Un agente de inteligencia artificial acaba de demostrar que no necesariamente es así. Investigadores de XBOW revelaron una vulnerabilidad en el kernel Linux capaz de transformar una escritura fuera de límites extremadamente restringida en una escalada local de privilegios hasta root.
El fallo, identificado como CVE-2026-72018, afecta al subsistema SMC-D/DIBS del kernel y ha recibido una puntuación CVSS de 7,8 sobre 10. Pero posiblemente lo más interesante de la investigación no sea únicamente la vulnerabilidad: gran parte del trabajo de descubrimiento, análisis y desarrollo de la explotación fue realizado por un agente autónomo de inteligencia artificial.
XBOW consiguió convertir una primitiva que inicialmente parecía poco interesante —escribir 16 bytes de valor cero en una posición parcialmente controlable de la memoria del kernel— en una técnica capaz de alterar las credenciales de un proceso y conseguir privilegios de superusuario.
La investigación ofrece así una doble advertencia: incluso los fallos aparentemente pequeños del kernel pueden tener consecuencias graves y los agentes de IA están alcanzando un nivel cada vez mayor de autonomía en investigación de vulnerabilidades.
Puede leer también | Un modelo de IA detecta una vulnerabilidad zero-day en Linux antes que los humanos
¿Qué es CVE-2026-72018?
CVE-2026-72018 es una vulnerabilidad de escritura fuera de límites —out-of-bounds write— presente en una parte del kernel Linux relacionada con DIBS loopback y Shared Memory Communications Direct, conocido como SMC-D.
En términos sencillos, una función encargada de copiar información hacia un buffer del kernel no comprobaba correctamente que la posición y el tamaño de la copia permanecieran dentro de la memoria que había sido reservada.
El esquema del error puede resumirse así:
Buffer reservado
+-----------------------------------+
| zona válida |
+-----------------------------------+
|
| falta comprobación
v
escritura fuera
de los límites
En software que trabaja dentro del kernel, una escritura fuera de límites es especialmente peligrosa porque puede modificar estructuras utilizadas para controlar procesos, permisos y otros elementos fundamentales del sistema operativo.
El problema está en dibs_loopback
La vulnerabilidad se encuentra concretamente en la rutina encargada de mover datos dentro del controlador dibs_loopback.
La operación terminaba realizando conceptualmente una copia similar a:
memcpy(buffer + offset, data, size);El problema estaba en que no existía una comprobación suficiente equivalente a:
offset + size <= tamaño_del_bufferSi un valor controlado provocaba que el desplazamiento superara los límites del buffer, determinados datos podían terminar escribiéndose sobre memoria perteneciente a otras estructuras del kernel.
La corrección incorporada posteriormente añade precisamente esa validación antes de realizar la copia.
¿Qué son SMC-D y DIBS?
Para comprender por qué este código había recibido relativamente poca atención conviene conocer su origen.
SMC —Shared Memory Communications— es una tecnología desarrollada originalmente por IBM para reducir el coste asociado a mover grandes cantidades de información mediante las rutas tradicionales de red.
Existen principalmente dos variantes:
| Tecnología | Función |
|---|---|
| SMC-R | Utiliza RDMA para comunicación de alto rendimiento. |
| SMC-D | Utiliza memoria compartida mediante dispositivos ISM. |
SMC-D estuvo históricamente muy asociado a sistemas IBM Z y hardware especializado.
Eso significaba que una gran cantidad de desarrolladores e investigadores Linux probablemente nunca ejecutaban esas rutas de código en sus computadoras habituales.
El cambio llegó con DIBS loopback
El panorama cambió cuando el kernel incorporó una abstracción denominada DIBS —Direct Internal Buffer Sharing— y un dispositivo virtual llamado:
dibs_loopbackGracias a él, determinadas funcionalidades de SMC-D pueden utilizarse sobre sistemas Linux x86 convencionales sin necesitar el hardware especializado para el que fueron concebidas originalmente.
Eso tiene una consecuencia de seguridad muy interesante:
Antes
------------------------------
Código asociado a hardware
especializado y poco accesible
Después
------------------------------
Mismo tipo de funcionalidad
|
v
loopback virtual
|
v
Linux x86 convencional
Una ruta que antes podía parecer extremadamente limitada pasó a formar parte de una superficie de ataque mucho más accesible.
El agente de IA comenzó analizando el protocolo
XBOW explica que su sistema adoptó un enfoque muy parecido al de un investigador de seguridad.
En lugar de limitarse a buscar patrones genéricos como:
memcpy()analizó el funcionamiento de SMC-D y se preguntó qué ocurriría si un peer fuera malicioso.
Durante la negociación de una conexión SMC aparecen diferentes valores que describen dónde se encuentran los buffers compartidos.
Entre ellos existe un campo denominado:
dmbe_idxque participa en el cálculo del desplazamiento utilizado posteriormente para escribir en memoria.
XBOW siguió ese dato desde el mensaje recibido hasta la función que finalmente realizaba la copia.
El kernel confiaba demasiado en un valor proporcionado por el peer
Conceptualmente, el cálculo podía terminar siendo algo parecido a:
tamaño buffer
x
índice recibido
=
desplazamiento
Ese desplazamiento llegaba posteriormente a la función que escribía dentro del buffer.
El problema era que el controlador software no verificaba adecuadamente que la operación continuara dentro de la región reservada.
En hardware ISM real existen mecanismos que ayudan a imponer límites sobre las regiones de memoria.
Pero el dispositivo software de loopback no disponía de esa misma protección.
El resultado: escritura fuera del buffer del kernel
El flujo vulnerable podía resumirse de esta manera:
Peer proporciona datos
|
v
dmbe_idx
|
v
cálculo del offset
|
v
move_data()
|
v
memcpy()
|
v
NO comprueba correctamente
offset + tamaño
|
v
escritura fuera del buffer
El kernel podría terminar modificando una zona de memoria que pertenecía a otro objeto.
Y ahí comienza la parte realmente interesante de la investigación.
La capacidad de escritura parecía demasiado pequeña para ser útil
XBOW descubrió que en el escenario local la vulnerabilidad no proporcionaba una capacidad cómoda para escribir cualquier información en cualquier posición.
Todo lo contrario.
La primitiva final era extremadamente limitada:
16 bytes de ceros en una posición parcialmente controlable.
En investigación de explotación de memoria, eso parece inicialmente bastante pobre.
Un atacante normalmente preferiría disponer de algo como:
"escribe cualquier valor"
+
"en cualquier dirección"
XBOW tenía algo más parecido a:
"escribe 16 ceros"
+
"en ciertas posiciones posibles"
Un investigador podría concluir razonablemente que no vale la pena invertir muchas horas intentando convertir algo tan limitado en una explotación funcional.
Precisamente ahí la IA tuvo una ventaja
XBOW describe esta vulnerabilidad bajo la idea de “No Time to Pwn”.
En investigación humana existe constantemente un problema de tiempo.
Un investigador encuentra diez posibles fallos y debe decidir cuáles tienen posibilidades suficientes como para justificar varios días de análisis.
Una primitiva tan débil podría descartarse:
Bug encontrado
|
v
Solo escribe ceros
|
v
Parece difícil de explotar
|
v
Buscar otro bug
Un agente autónomo puede permitirse dedicar muchas más iteraciones a ese camino sin consumir las mismas horas de atención humana.
Y eso fue precisamente lo que ocurrió.
16 bytes eran suficientes si se elegía correctamente el objetivo
El siguiente problema era encontrar dentro del kernel algo donde escribir ceros fuera especialmente útil.
La solución apareció en una de las estructuras más sensibles de Linux:
cred.
El kernel utiliza esta estructura para almacenar las credenciales de cada proceso.
Entre sus campos aparecen:
uid gid suid sgid euid egid fsuid fsgid
Es decir, información que determina quién es el usuario y con qué permisos se ejecuta el proceso.
En Linux, root es el usuario 0
En sistemas Linux:
UID 0 = rootEsto introduce una coincidencia particularmente útil para un atacante que únicamente puede escribir ceros.
Si consigue que esos ceros alcancen campos adecuados de la estructura cred, determinados identificadores del proceso pueden transformarse en:
0y el kernel puede interpretar posteriormente que el proceso dispone de identidad privilegiada.
Por tanto, la limitación aparentemente enorme de la vulnerabilidad:
"solo puedo escribir ceros"
se convierte inesperadamente en una ventaja cuando:
root = UID 0
Del pequeño fallo de memoria al acceso root
La lógica de la explotación desarrollada durante la investigación puede entenderse conceptualmente así:
Escritura fuera de límites
|
v
16 bytes de ceros
|
v
Memoria cercana a objetos cred
|
v
Alteración de identificadores
del proceso
|
v
UID efectivo = 0
|
v
Privilegios root
Esta es la razón por la que una escritura aparentemente insignificante puede convertirse en un problema de alta severidad.
No necesitó una segunda fuga de memoria
Otro elemento técnico interesante es que XBOW consiguió demostrar la escalada sin combinar el fallo con una vulnerabilidad adicional destinada a revelar direcciones de memoria.
En explotaciones modernas del kernel es frecuente necesitar varios componentes:
memory leak
+
write primitive
+
heap manipulation
=
explotación
En esta investigación, XBOW consiguió construir una prueba utilizando únicamente la primitiva proporcionada por CVE-2026-72018, apoyándose en manipulación de la disposición de objetos en memoria.
Pero no significa que cualquier usuario remoto pueda convertirse en root
Este es probablemente el matiz más importante de toda la noticia.
CVE-2026-72018 no equivale a una vulnerabilidad que permita entrar desde Internet a cualquier servidor Linux y obtener root inmediatamente.
El escenario de explotación demostrado por XBOW es:
Atacante ya está localmente
en el sistema
|
+
dispone de CAP_NET_ADMIN
|
v
explota la vulnerabilidad
|
v
root
La investigación necesitó específicamente CAP_NET_ADMIN para preparar determinados elementos relacionados con SMC-D y manipular tráfico local durante la prueba.
¿Qué es CAP_NET_ADMIN?
Linux permite dividir parte de los privilegios tradicionales de root en capacidades independientes.
CAP_NET_ADMIN permite ejecutar distintas operaciones administrativas relacionadas con la red.
Puede aparecer en determinados:
- Contenedores.
- Servicios de red.
- Herramientas de infraestructura.
- Namespaces.
- Aplicaciones que manipulan interfaces y reglas de red.
Por tanto, el requisito reduce considerablemente la superficie de explotación frente a un fallo accesible a cualquier usuario, pero no elimina el riesgo.
En infraestructuras de contenedores resulta particularmente importante controlar qué workloads reciben esta capability.
El CVSS refleja precisamente que estamos ante una vulnerabilidad local
CVE-2026-72018 tiene una puntuación:
CVSS 3.1: 7.8 / 10 — HIGHSu vector la caracteriza como una vulnerabilidad de ataque local.
| Característica | CVE-2026-72018 |
|---|---|
| Vector | Local |
| Complejidad | Baja según CVSS |
| Privilegios | Requeridos |
| Interacción del usuario | No requerida |
| Confidencialidad | Impacto alto |
| Integridad | Impacto alto |
| Disponibilidad | Impacto alto |
La prueba de XBOW tampoco fue infalible
Existe otro dato necesario para poner la investigación en contexto.
XBOW probó su escalada de privilegios sobre:
Ubuntu 24.04
Linux 7.1.0-rc6
x86_64utilizando un kernel experimental y con las mitigaciones del kernel desactivadas para demostrar que aquella única primitiva era suficiente.
Durante pruebas realizadas sobre 100 arranques separados, el exploit consiguió la escalada en:
22 de 100 arranquesEl primer éxito ocurrió en el séptimo.
Por tanto, no estamos ante una demostración que garantice root instantáneo y universal sobre cualquier distribución.
¿Significa eso que la vulnerabilidad no es peligrosa?
No.
El objetivo del experimento era responder una pregunta mucho más concreta:
¿Es suficiente esa pequeña escritura fuera de límites para conseguir escalada de privilegios?
La respuesta fue sí.
XBOW señala además que la prueba fue deliberadamente construida alrededor de esa única primitiva y que técnicas adicionales podrían potencialmente aumentar la confiabilidad.
Puede leer también | Herramientas esenciales para proteger tu Sistema Operativo Linux de Hackers
Lo sorprendente no es solamente el bug: es quién hizo gran parte del trabajo
XBOW se define como una plataforma autónoma de investigación de seguridad.
Durante esta investigación, el agente asumió buena parte de tareas que tradicionalmente realizarían especialistas humanos:
- Modelado de amenazas.
- Lectura del código del kernel.
- Identificación del fallo.
- Validación experimental.
- Análisis de la primitiva de memoria.
- Desarrollo de la estrategia de explotación.
Sin embargo, la propia empresa reconoce que todavía fueron necesarias varias intervenciones humanas.
La IA también se equivocó durante la investigación
La historia resulta especialmente interesante porque XBOW no presenta al agente como un sistema infalible.
Hubo varias ocasiones donde el modelo llegó a callejones sin salida.
Por ejemplo, inicialmente concluyó que convertir el problema en una escalada local era inviable debido a determinadas características del tráfico loopback.
Un investigador humano detectó una posibilidad que el agente había considerado y posteriormente descartado demasiado pronto.
Le pidió que volviera a explorarla.
Esa intervención terminó desbloqueando el camino hacia la prueba local.
El agente llegó a confundirse sobre su propia capacidad de escritura
Durante otra fase, XBOW continuaba razonando como si dispusiera de una escritura mucho más potente de la que realmente tenía.
Los investigadores tuvieron que obligarlo a probar experimentalmente la primitiva.
El resultado confirmó:
NO: escribir cualquier dato SÍ: escribir 16 bytes de ceros
Solo después de demostrarlo experimentalmente el agente corrigió su estrategia.
Después encontró el objetivo perfecto: cred
Una vez aceptada la limitación, el problema pasó a ser:
“Si únicamente podemos escribir ceros, ¿qué estructura sería especialmente valiosa?”
XBOW terminó identificando las credenciales de los procesos Linux como objetivo.
La idea resulta elegante porque convierte la mayor debilidad de la primitiva en precisamente lo necesario para conseguir el resultado:
solo escribe ceros
|
v
root utiliza UID 0
|
v
cred es un objetivo ideal
IA y humanos trabajando juntos encontraron el camino
La investigación muestra un modelo que probablemente veremos cada vez con mayor frecuencia.
Agente IA ----------------------- Lee enormes cantidades de código Ejecuta experimentos Genera hipótesis Trabaja durante horas Investigador humano ----------------------- Cuestiona supuestos Decide prioridades Detecta caminos abandonados Redirige la estrategia
No se trata necesariamente de reemplazar inmediatamente a los investigadores humanos.
Se trata de multiplicar la cantidad de caminos que pueden investigarse.
Los agentes pueden investigar bugs que un humano descartaría por falta de tiempo
Ese puede ser el cambio más importante.
En un proyecto enorme como el kernel Linux existen continuamente:
- Nuevos controladores.
- Subsistemas antiguos.
- Abstracciones.
- Compatibilidad heredada.
- Protocolos poco utilizados.
Un investigador tiene un número limitado de horas.
Un agente puede continuar estudiando una hipótesis aparentemente mediocre mientras la persona trabaja sobre otra.
Esto cambia la economía de la investigación de vulnerabilidades.
El kernel Linux representa precisamente el tipo de objetivo ideal para agentes
Linux contiene millones de líneas de código acumuladas durante décadas.
Dentro del árbol del kernel existen componentes ampliamente revisados y otros mucho menos utilizados.
Para un agente capaz de:
- Leer C.
- Seguir flujos de datos.
- Analizar commits.
- Consultar documentación.
- Compilar kernels.
- Ejecutar máquinas virtuales.
- Interpretar crashes.
el kernel representa un campo enorme de investigación automatizable.
La virtualización de hardware antiguo puede abrir superficies inesperadas
CVE-2026-72018 también deja otra lección independiente de la IA.
El código original de un subsistema puede haber sido desarrollado bajo determinados supuestos de hardware.
Por ejemplo:
Hardware real
|
impone límites
de memoria
Cuando posteriormente ese comportamiento se implementa mediante software:
dispositivo virtual
|
v
el software debe implementar
explícitamente los mismos controles
Si esas garantías no se reproducen, puede aparecer una nueva superficie de vulnerabilidad.
El parche es conceptualmente sorprendentemente sencillo
A pesar de toda la complejidad necesaria para explotar el fallo, la corrección del problema fundamental es sencilla:
comprobar los límites antes de copiar.
Conceptualmente:
¿offset es válido?
|
+
¿size cabe?
|
v
Sí ------> memcpy
|
No
|
v
-EINVAL
El kernel ahora rechaza operaciones cuyo desplazamiento o tamaño pueda superar el buffer registrado.
¿Qué versiones están afectadas?
El código vulnerable apareció en ramas relativamente recientes del kernel.
De acuerdo con la información publicada en OSV para el código upstream, existen rangos que comienzan con Linux 6.10 y que fueron corregidos en diferentes ramas estables.
| Rama afectada | Versión de corrección indicada |
|---|---|
| 6.10 y rama estable correspondiente | 6.12.97 |
| Ramas posteriores | 6.18.40 |
| Rama 7.x afectada | 7.1.5 |
Sin embargo, no debe decidirse si un equipo es vulnerable únicamente mirando el número del kernel.
Las distribuciones aplican backports y mantienen árboles de kernel diferentes.
Debian ya muestra el problema corregido en sus ramas afectadas
El Security Tracker de Debian indica que versiones antiguas como Bullseye y Bookworm no contienen el código vulnerable original, mientras que las ramas afectadas posteriores han recibido versiones corregidas.
Esta diferencia demuestra por qué resulta importante consultar siempre el aviso de seguridad de la distribución utilizada.
Ubuntu presenta un escenario diferente según la versión
Canonical clasifica CVE-2026-72018 con una puntuación CVSS de 7,8.
Según el estado publicado por Ubuntu a comienzos de octubre de 2026:
- Ubuntu 24.04 LTS aparece como no afectado en su kernel distribuido.
- Ubuntu 22.04 LTS aparece como no afectado.
- Ubuntu 20.04 LTS aparece como no afectado.
- Ubuntu 26.04 LTS aparece afectado en determinados paquetes y con trabajo de corrección en curso.
Esto puede parecer contradictorio con la demostración realizada sobre Ubuntu 24.04.
La explicación es que XBOW utilizó sobre esa instalación un kernel Linux 7.1.0-rc6 experimental, no necesariamente el kernel estándar distribuido por Ubuntu 24.04.
Cómo comprobar qué kernel estás utilizando
En cualquier servidor Linux:
uname -rTambién podemos consultar:
cat /etc/os-releaseEsto proporciona dos datos fundamentales:
Distribución + versión kernel
Después debemos compararlos con el aviso de seguridad específico del proveedor.
No descargues un kernel al azar únicamente por ver el CVE
En servidores de producción, la respuesta correcta normalmente será utilizar las actualizaciones proporcionadas por la propia distribución.
Por ejemplo:
Debian/Ubuntu:
sudo apt update
sudo apt full-upgradeFedora/RHEL y derivados, según la distribución:
sudo dnf upgradeDespués de actualizar un kernel será necesario arrancar utilizando la nueva versión para que la corrección entre realmente en funcionamiento.
Comprobar el kernel después de reiniciar
No basta con instalar el paquete.
Después del reinicio:
uname -rdebe mostrar la versión que realmente se encuentra ejecutando.
Esto es especialmente importante en servidores donde pueden acumularse kernels instalados pero nunca activados porque la máquina no fue reiniciada.
CAP_NET_ADMIN debería concederse únicamente cuando sea imprescindible
La vulnerabilidad deja también una importante lección para Docker, Podman, Kubernetes y otros entornos de contenedores.
No debería utilizarse indiscriminadamente:
--cap-add=NET_ADMINsolo para solucionar rápidamente un problema de permisos.
CAP_NET_ADMIN proporciona numerosas capacidades de administración de red y amplía significativamente lo que un proceso puede hacer dentro de determinados entornos.
El principio debería continuar siendo:
conceder únicamente las capabilities estrictamente necesarias.
Un contenedor no debería ejecutarse como privileged sin necesidad
El problema es todavía mayor con:
--privilegedEse modo concede al contenedor una cantidad de privilegios que elimina gran parte de las barreras que normalmente lo separan del host.
En presencia de vulnerabilidades de kernel, esos permisos adicionales pueden convertirse en piezas útiles para una cadena de escalada.
La defensa sigue siendo la misma: reducir la superficie
CVE-2026-72018 puede parecer extremadamente especializada, pero las medidas defensivas son conocidas:
- Mantener kernels actualizados.
- No conceder capabilities innecesarias.
- Aplicar mínimo privilegio.
- Evitar contenedores privilegiados.
- Monitorizar servidores.
- Limitar acceso shell.
- Separar workloads de diferente nivel de confianza.
- Utilizar kernels y distribuciones soportadas.
Puede leer también | Las mejores herramientas de código abierto para proteger su servidor Linux
¿Existe evidencia de explotación activa?
Por ahora, la divulgación pública de XBOW se centra en la investigación y en demostrar la explotabilidad del fallo.
No debe confundirse la existencia de una prueba de escalada con evidencia de campañas activas explotando CVE-2026-72018 en servidores de Internet.
Además, como se ha señalado, la vulnerabilidad requiere un escenario local específico y no constituye directamente una vía de acceso remoto.
Un CVE local puede seguir siendo muy peligroso
En seguridad existe la tendencia a prestar toda la atención a vulnerabilidades remotas.
Pero numerosos ataques reales funcionan en dos etapas:
FASE 1
Conseguir acceso limitado
mediante aplicación,
credencial o servicio
|
v
FASE 2
Explotar vulnerabilidad local
|
v
ROOT
Una escalada local puede transformar una cuenta restringida en control completo del servidor.
Por eso este tipo de vulnerabilidades continúa siendo especialmente relevante en:
- Servidores multiusuario.
- Cloud.
- Contenedores.
- Plataformas CI/CD.
- Hosting compartido.
- Infraestructura de desarrollo.
La IA está entrando en una nueva etapa de investigación ofensiva
Durante los primeros años de los modelos generativos se discutía principalmente si podían:
- Explicar código.
- Generar scripts.
- Encontrar errores sencillos.
- Resolver desafíos CTF.
Ahora aparecen sistemas capaces de participar en procesos mucho más extensos:
leer código | crear hipótesis | compilar | ejecutar | observar fallo | modificar estrategia | desarrollar explotación
Eso sitúa los agentes mucho más cerca de un investigador automatizado que de un simple chatbot.
El hallazgo también tiene una cara positiva para Linux
Puede resultar inquietante que una IA consiga desarrollar técnicas de escalada.
Pero existe otra forma de interpretarlo.
El kernel Linux dispone de una superficie enorme que ningún equipo humano puede auditar continuamente de forma exhaustiva.
Agentes especializados pueden dedicar tiempo a:
- Drivers poco utilizados.
- Protocolos antiguos.
- Subsistemas especializados.
- Nuevos commits.
- Código recientemente virtualizado.
y encontrar problemas antes de que los descubran actores maliciosos.
La carrera será encontrar los fallos primero
La pregunta que deja CVE-2026-72018 no es si la inteligencia artificial será utilizada para encontrar vulnerabilidades.
Eso ya está ocurriendo.
La pregunta real será:
¿quién las encontrará primero?
Agente defensivo
|
v
encuentra bug
|
v
parche
|
v
actualización
Agente ofensivo
|
v
encuentra bug
|
v
exploit
|
v
ataque
La misma automatización puede reducir el tiempo disponible entre descubrimiento, corrección y explotación.
Checklist para administradores Linux
- Identificar la distribución y versión instalada.
- Consultar el kernel en ejecución con uname -r.
- Revisar el aviso CVE del proveedor de la distribución.
- Aplicar las actualizaciones del kernel disponibles.
- Reiniciar cuando la actualización lo requiera.
- Verificar nuevamente el kernel activo.
- Auditar procesos y contenedores que utilizan CAP_NET_ADMIN.
- Eliminar capabilities innecesarias.
- Evitar contenedores privileged sin justificación.
- Mantener inventario de versiones del kernel.
- Monitorizar nuevos avisos de seguridad.
Recomendamos
- Un modelo de IA detecta una vulnerabilidad zero-day en Linux antes que los humanos
- Herramientas esenciales para proteger tu Sistema Operativo Linux de Hackers
- Las mejores herramientas de código abierto para proteger su servidor Linux
En resumen
XBOW descubrió y explotó CVE-2026-72018, una vulnerabilidad de escritura fuera de límites en el kernel Linux con puntuación CVSS 7,8.
El fallo se encuentra en el controlador DIBS loopback utilizado por SMC-D y se produce porque una operación de copia no comprobaba correctamente que el desplazamiento y tamaño permanecieran dentro del buffer asignado.
La capacidad obtenida inicialmente parecía extremadamente limitada: aproximadamente 16 bytes de ceros en una posición parcialmente controlada.
Sin embargo, XBOW consiguió dirigir esa escritura hacia estructuras de credenciales del kernel y demostrar una escalada local hasta root.
El escenario demostrado requiere acceso local y CAP_NET_ADMIN. Además, la prueba presentada por los investigadores se realizó con mitigaciones del kernel desactivadas y no tuvo éxito en todos los arranques.
El fallo ya ha sido corregido upstream y las distribuciones están aplicando o han aplicado sus correspondientes actualizaciones según las ramas afectadas.
Conclusión editorial
CVE-2026-72018 es interesante por dos razones completamente diferentes.
La primera es puramente técnica.
Demuestra que en el kernel Linux incluso una primitiva aparentemente insignificante puede terminar siendo peligrosa si consigue modificar el objeto adecuado.
Dieciséis bytes de ceros parecían poca cosa.
Hasta que alguien recordó que:
root = UID 0La segunda razón puede ser todavía más importante a largo plazo.
Gran parte del trabajo necesario para llegar desde una línea de código vulnerable hasta una demostración funcional de escalada fue realizado por un agente de inteligencia artificial.
XBOW no trabajó perfectamente.
Se equivocó, abandonó caminos útiles y necesitó que investigadores humanos cuestionaran algunas de sus conclusiones.
Pero también hizo algo que los humanos tienen dificultad para hacer a gran escala: continuar investigando durante mucho tiempo un fallo que parecía demasiado pequeño y demasiado incómodo como para justificar el esfuerzo.
Esa puede convertirse precisamente en una de las grandes ventajas de la IA aplicada a ciberseguridad.
El kernel Linux contiene millones de líneas, innumerables controladores y décadas de código escrito bajo contextos tecnológicos diferentes.
Ningún equipo humano puede revisar cada camino continuamente.
Los agentes sí pueden multiplicar esa capacidad.
El reto será conseguir que estas herramientas trabajen primero para los defensores.
Porque si un agente puede encontrar una escritura de 16 bytes que nadie consideró especialmente interesante y transformarla en root, el concepto de “bug demasiado pequeño para preocuparse” acaba de volverse mucho menos cómodo.
Fuentes: XBOW — No Time to Pwn: CVE-2026-72018, Ubuntu Security — CVE-2026-72018, Debian Security Tracker y OSV — CVE-2026-72018.
Etiquetas: Linux, Linux Kernel, CVE-2026-72018, XBOW, inteligencia artificial, vulnerabilidades, ciberseguridad, root, escalada de privilegios, SMC-D, DIBS, kernel security, agentes de IA.
