Una nueva vulnerabilidad Linux demuestra hasta qué punto la inteligencia artificial está empezando a transformar también la investigación avanzada de ciberseguridad.
El fallo, identificado como CVE-2026-72018, afecta al kernel de Linux y permite una escritura fuera de límites en memoria dentro del subsistema DIBS/SMC-D. Su gravedad oficial es CVSS 7.8 — Alta, por lo que no debe clasificarse técnicamente como crítica. Google Kernel Repositories
La empresa de seguridad XBOW consiguió desarrollar una cadena de explotación capaz de convertir una primitiva aparentemente muy limitada —una escritura de apenas 16 bytes— en una escalada local de privilegios hasta root. XBOW
Sin embargo, existe un matiz especialmente importante:
no fue una IA trabajando completamente sola.
Según la propia XBOW, su sistema autónomo realizó gran parte del:
- modelado de amenazas;
- análisis del código;
- descubrimiento;
- validación;
- desarrollo del exploit.
Pero en varios momentos importantes fueron necesarias decisiones humanas para redirigir la investigación. XBOW
Por tanto, el caso no demuestra simplemente que:
“una IA encontró algo que ningún humano podía encontrar”.
Demuestra algo probablemente más interesante:
IA + investigadores humanos pueden profundizar durante mucho más tiempo en candidatos que una persona podría descartar por falta de tiempo.
Vulnerabilidad Linux CVE-2026-72018: qué problema existe
El fallo se encuentra en la implementación de:
DIBS loopback
utilizada por:
SMC-D — Shared Memory Communications Direct.
La función vulnerable realizaba una operación memcpy() sobre un búfer de memoria registrado sin comprobar correctamente que:
offset + tamaño
permaneciera dentro de los límites del búfer.
Eso permitía provocar una:
Out-of-Bounds Write
o:
escritura fuera de límites. GitHub
En términos sencillos:
el kernel podía terminar escribiendo información donde no debía.
Y cuando hablamos de memoria del kernel, una corrupción aparentemente pequeña puede convertirse en un problema mucho mayor.
¿Qué es una escritura fuera de límites?
Imagine que un programa reserva una zona de memoria con espacio para:
100 bytes.
Sin embargo, debido a una comprobación incorrecta intenta escribir en:
el byte 120.
Está modificando memoria que pertenece a otra estructura.
Dependiendo de qué exista allí, esto puede provocar:
- corrupción de memoria;
- fallo del kernel;
- bloqueo;
- modificación de estructuras internas;
- escalada de privilegios.
En CVE-2026-72018, los investigadores consiguieron aprovechar ese comportamiento para construir una escalada local hasta root. XBOW
Vulnerabilidad Linux: ¿por qué apenas 16 bytes fueron suficientes?
Este es probablemente el aspecto técnicamente más interesante.
La capacidad de escritura encontrada inicialmente parecía muy limitada.
XBOW la describe como una operación capaz de escribir únicamente:
16 bytes con valor cero
en una posición parcialmente controlable.
Un investigador puede encontrar un comportamiento así y pensar:
“demasiado limitado para conseguir algo útil”.
XBOW reconoce que, dentro de un proceso exclusivamente humano, ese candidato probablemente habría sido descartado para dedicar tiempo a otros fallos más prometedores. XBOW
Sin embargo, el sistema siguió trabajando.
Finalmente logró convertir esa pequeña capacidad de corrupción en:
escalada local de privilegios.
Vulnerabilidad Linux e IA: el valor estuvo también en la persistencia
Aquí aparece una de las características más interesantes de la investigación con agentes autónomos.
Un investigador humano tiene:
- jornada limitada;
- muchos objetivos;
- prioridades;
- presupuesto;
- fatiga.
Puede encontrar una anomalía que parece poco explotable y decidir:
“no merece una semana de trabajo”.
Una herramienta de IA puede continuar:
- leyendo código;
- formulando hipótesis;
- preparando pruebas;
- descartando caminos;
- buscando nuevas combinaciones.
El coste marginal de seguir investigando puede ser mucho menor.
Por tanto, la ventaja no está necesariamente en que:
“la IA sea más inteligente que todos los investigadores”.
Puede estar en que:
puede dedicar una enorme cantidad de iteraciones a un problema concreto.
Vulnerabilidad Linux: el papel de SMC-D
Para entender el hallazgo hay que conocer brevemente SMC-D.
SMC significa:
Shared Memory Communications.
SMC-D fue diseñado originalmente para permitir comunicaciones eficientes utilizando memoria compartida en determinados entornos, especialmente relacionados históricamente con sistemas IBM Z.
Durante mucho tiempo, estas rutas de código eran poco habituales fuera de esa arquitectura.
Por tanto:
la superficie de ataque práctica era limitada.
De IBM Z a servidores Linux x86
La situación cambió con la incorporación de una abstracción denominada:
DIBS — Direct Internal Buffer Sharing
y de un dispositivo virtual:
dibs_loopback.
Eso permitió ejecutar determinadas rutas de SMC-D mediante loopback sobre sistemas Linux x86 convencionales, sin necesitar el hardware original asociado históricamente a IBM Z. XBOW
Y ahí aparece una enseñanza muy importante.
Código que durante años era:
difícil de alcanzar
puede convertirse posteriormente en:
superficie de ataque accesible
cuando añadimos nuevas capas de compatibilidad o virtualización.
Vulnerabilidad Linux: el cambio de contexto crea nuevos riesgos
El código original podía haber sido diseñado pensando en:
- hardware concreto;
- dispositivos confiables;
- determinadas condiciones.
Después se introduce:
una implementación virtual.
La lógica sigue existiendo.
Pero el modelo de amenazas cambia.
En palabras prácticas:
algo que antes solo podía ocurrir en un entorno muy específico ahora puede ejecutarse en hardware convencional.
Por tanto, cada vez que se virtualiza o generaliza una funcionalidad antigua, merece la pena volver a preguntarse:
¿siguen siendo válidas las mismas suposiciones de seguridad?
Vulnerabilidad Linux: CVE-2026-72018 no es un ataque remoto desde Internet
Este punto es fundamental.
El vector oficial de CVE-2026-72018 es:
Local.
Su puntuación CVSS es:
7.8 — Alta
con:
- complejidad baja;
- privilegios bajos;
- sin interacción del usuario;
- impacto alto sobre confidencialidad;
- integridad;
- disponibilidad. Ubuntu
Por tanto, no estamos ante una vulnerabilidad que permita simplemente:
enviar un paquete desde Internet y conseguir root.
El atacante necesita previamente una posición local adecuada en el sistema.
¿Necesita CAP_NET_ADMIN?
Aquí existe una diferencia interesante entre la clasificación CVE y la prueba práctica publicada por XBOW.
La puntuación oficial describe el fallo como:
privilegios bajos.
Sin embargo, el exploit publicado por XBOW necesitó en su configuración de prueba la capacidad Linux:
CAP_NET_ADMIN
para manipular el tráfico loopback mediante NFQUEUE y modificar los mensajes necesarios para desencadenar la corrupción. XBOW
Por tanto, lo correcto es diferenciar:
condiciones teóricas de la vulnerabilidad
de:
condiciones concretas del exploit demostrado por XBOW.
Vulnerabilidad Linux y CAP_NET_ADMIN
CAP_NET_ADMIN concede privilegios relacionados con la administración de red.
Puede permitir operaciones como:
- modificar determinadas configuraciones;
- gestionar reglas;
- trabajar con interfaces;
- configurar diferentes elementos de networking.
No equivale automáticamente a:
root completo.
Sin embargo, tampoco debería concederse indiscriminadamente.
Precisamente por eso este caso resulta especialmente interesante en entornos con:
- contenedores;
- servidores;
- plataformas de desarrollo;
- infraestructuras cloud.
Vulnerabilidad Linux: ¿afecta a Docker?
Aquí debemos evitar otro titular demasiado general.
No es correcto afirmar que:
“cualquier contenedor Docker puede escapar automáticamente hasta root”.
Los contenedores comparten el kernel del host.
Por tanto, una vulnerabilidad del kernel puede convertirse en una vía de escape del aislamiento si el atacante reúne las condiciones necesarias.
Sin embargo, la explotación demostrada depende de:
- versión del kernel;
- disponibilidad de DIBS;
- capacidades concedidas;
- configuración;
- mitigaciones.
En particular, los contenedores estándar no deberían recibir capacidades sensibles como CAP_NET_ADMIN sin una necesidad real.
Vulnerabilidad Linux y Kubernetes
La misma lógica se aplica a Kubernetes.
Los pods terminan ejecutándose sobre nodos Linux.
Por tanto:
muchos contenedores pueden compartir un mismo kernel.
Si una aplicación maliciosa consigue aprovechar una vulnerabilidad de kernel, el riesgo puede superar el límite lógico del contenedor.
Pero nuevamente:
vulnerabilidad Linux ≠ escape automático de Kubernetes.
Hay que evaluar:
- kernel utilizado;
- runtime;
- capabilities;
- securityContext;
- políticas;
- versión corregida.
El kernel compartido es una ventaja y también un riesgo
Los contenedores son muy eficientes porque no ejecutan un kernel independiente por aplicación.
Comparten el del host.
Esto permite:
✅ menor consumo
✅ arranque rápido
✅ gran densidad de workloads
Pero también implica:
el kernel es una frontera crítica de seguridad.
Si el kernel falla:
muchos contenedores dependen de la misma capa vulnerable.
Vulnerabilidad Linux: no conceder capabilities por comodidad
Un error frecuente en contenedores consiste en añadir:
privileged: true
o capabilities adicionales cuando una aplicación presenta problemas.
Así:
“funciona”.
Pero también aumenta drásticamente su capacidad.
En lugar de conceder:
todos los privilegios
deberíamos identificar:
cuál necesita realmente.
Especialmente para:
CAP_SYS_ADMIN;CAP_NET_ADMIN;- acceso a dispositivos;
- montaje del filesystem del host.
El principio continúa siendo:
mínimo privilegio.
Vulnerabilidad Linux y microVM
El caso también ha reabierto el debate sobre:
contenedor frente a máquina virtual.
Una máquina virtual convencional dispone normalmente de:
su propio kernel.
Por tanto, una vulnerabilidad en el kernel invitado no implica automáticamente comprometer el kernel del host.
En un contenedor tradicional:
host y contenedor comparten kernel.
Por eso algunas infraestructuras que ejecutan código de terceros o workloads poco confiables utilizan:
- microVM;
- Kata Containers;
- Firecracker;
- aislamiento mediante hipervisor.
¿Significa que las máquinas virtuales son siempre seguras?
No.
También existen vulnerabilidades en:
- hipervisores;
- virtualización;
- dispositivos virtuales.
Sin embargo, proporcionan una frontera diferente.
La superficie expuesta al invitado puede ser menor que la enorme cantidad de interfaces disponibles directamente en un kernel Linux completo.
Por eso una empresa debe decidir el nivel de aislamiento según:
el riesgo del workload.
Vulnerabilidad Linux: Firecracker y Kata Containers
Soluciones como Firecracker y Kata Containers intentan combinar:
velocidad de contenedores
con:
aislamiento mediante virtualización.
Pueden resultar especialmente interesantes en:
- multitenant;
- ejecución de código no confiable;
- funciones serverless;
- plataformas de desarrollo.
Sin embargo, no significa que todas las empresas deban reemplazar Docker mañana.
El modelo de aislamiento debe adaptarse al riesgo.
Vulnerabilidad Linux: qué versiones están afectadas
El registro de la vulnerabilidad sitúa la introducción del código afectado en la rama 6.10 y refleja correcciones posteriores en diferentes ramas del kernel.
Entre las versiones que incorporan la corrección aparecen:
- 6.12.97 o posteriores dentro de 6.12
- 6.18.40 o posteriores dentro de 6.18
- 7.1.5 o posteriores dentro de 7.1
- 7.2 y posteriores. OpenCVE
Sin embargo, existe una consideración todavía más importante:
no recomendamos decidir únicamente comparando números de kernel.
Vulnerabilidad Linux: los fabricantes aplican backports
Las distribuciones Linux pueden aplicar un parche de seguridad a:
un kernel aparentemente antiguo
sin cambiar a la versión upstream donde apareció originalmente la corrección.
Esto se denomina:
backport.
Por tanto, comprobar únicamente:
uname -r
y comparar números puede generar conclusiones incorrectas.
Lo correcto es revisar:
el advisory de la distribución.
Debian y CVE-2026-72018
Debian mantiene información específica para esta vulnerabilidad.
Su tracker refleja diferentes estados según la versión de la distribución y los paquetes concretos, incluyendo versiones corregidas dentro de las ramas soportadas. Security Tracker
Esto demuestra por qué debemos analizar:
distribución + paquete + kernel instalado
y no solamente:
versión upstream.
Ubuntu y CVE-2026-72018
Canonical también mantiene su propio seguimiento.
Ubuntu asigna a CVE-2026-72018:
CVSS 7.8 — Alta
aunque su prioridad interna aparece como Medium.
Además, el impacto varía entre kernels y versiones de Ubuntu: algunas aparecen como no afectadas y otras como vulnerables o todavía pendientes de corrección. Ubuntu
Por tanto:
“utilizamos Ubuntu”
no es información suficiente para determinar exposición.
Hay que revisar:
- release;
- kernel;
- paquete;
- estado del advisory.
Amazon Linux tampoco está afectado automáticamente
Los avisos de Amazon muestran que varias familias actuales de Amazon Linux aparecen como:
Not Affected
para CVE-2026-72018. Explora Alas
Esta diferencia es especialmente importante en cloud.
Dos servidores pueden ejecutar:
Linux
y tener situaciones completamente diferentes.
Vulnerabilidad Linux: qué debería hacer una empresa
La principal recomendación es:
consultar el aviso de seguridad del proveedor de la distribución e instalar el kernel corregido correspondiente.
No recomendamos:
descargar un kernel aleatorio de Internet
ni:
compilar manualmente un parche
en producción salvo que exista un motivo técnico y personal especializado.
En servidores empresariales:
seguir el canal de actualización soportado suele ser la opción adecuada.
Un kernel actualizado necesita normalmente reinicio
Este detalle es importante.
Podemos ejecutar:
apt update
y:
apt upgrade
y pensar:
“ya está actualizado”.
Pero el servidor puede continuar ejecutando:
el kernel antiguo cargado en memoria.
Por tanto, después de instalar una actualización de kernel debemos comprobar:
qué versión está ejecutándose realmente.
En muchos escenarios será necesario:
reiniciar.
Vulnerabilidad Linux: el reinicio también debe planificarse
En un servidor empresarial no siempre podemos reiniciar inmediatamente.
Puede haber:
- bases de datos;
- servicios web;
- aplicaciones;
- máquinas virtuales.
Por tanto, necesitamos:
- identificar vulnerabilidad;
- evaluar exposición;
- instalar actualización;
- planificar ventana;
- reiniciar;
- comprobar servicio;
- verificar kernel activo.
La gestión de vulnerabilidades también es:
gestión operativa.
Vulnerabilidad Linux e inteligencia artificial: XBOW no trabajó completamente sola
El titular:
“una IA encontró lo que los humanos no pudieron ver”
es atractivo.
Pero simplifica demasiado lo ocurrido.
La propia XBOW explica que el agente realizó una parte muy importante del trabajo autónomo.
Sin embargo, también reconoce intervenciones humanas en momentos clave de la investigación. XBOW
Por tanto, el caso representa mejor:
investigación aumentada mediante IA
que:
sustitución total del investigador.
La IA hizo el trabajo que normalmente consume semanas
Eso no reduce su importancia.
Precisamente ahí está el cambio.
Una herramienta autónoma puede:
- revisar grandes cantidades de código;
- mantener contexto;
- desarrollar hipótesis;
- ejecutar pruebas;
- modificar estrategias.
El investigador puede centrarse en:
las decisiones de mayor valor.
Esta combinación puede aumentar drásticamente la velocidad para localizar vulnerabilidades complejas.
Vulnerabilidad Linux: la IA también ayudará a los defensores
Cuando hablamos de IA en ciberseguridad solemos pensar únicamente en:
atacantes automatizados.
Sin embargo, el descubrimiento de CVE-2026-72018 demuestra el otro lado.
La IA puede utilizarse para:
- revisar código;
- descubrir vulnerabilidades;
- analizar amenazas;
- encontrar configuraciones inseguras;
- desarrollar tests;
- priorizar problemas.
Por tanto:
IA ofensiva
y:
IA defensiva
seguirán evolucionando simultáneamente.
Encontrar vulnerabilidades más rápido obliga también a parchear más rápido
Existe una consecuencia directa.
Si los investigadores pueden descubrir vulnerabilidades a mayor velocidad:
también pueden hacerlo los atacantes.
Por tanto, las empresas necesitan reducir el tiempo entre:
publicación
y:
corrección.
El ciclo debería aproximarse a:
detectar
↓
evaluar
↓
priorizar
↓
parchear
↓
verificar
Vulnerabilidad Linux: un servidor sin exposición web también puede ser vulnerable
Otra idea equivocada sería:
“este Linux no tiene página web, por tanto no importa”.
CVE-2026-72018 es:
una vulnerabilidad local del kernel.
Por tanto, lo importante es si un atacante puede obtener previamente una posición adecuada dentro del sistema.
El acceso inicial podría provenir de:
- aplicación vulnerable;
- credenciales robadas;
- contenedor comprometido;
- servicio mal configurado.
Después:
la escalada de privilegios puede convertirse en la segunda fase.
Las vulnerabilidades locales importan después del primer acceso
Imagine:
Aplicación web comprometida
↓
usuario de servicio limitado
↓
CVE local
↓
root
La primera vulnerabilidad proporciona:
entrada.
La segunda proporciona:
privilegios.
Por eso no debemos analizar cada CVE como un incidente aislado.
Los atacantes pueden:
encadenarlas.
Vulnerabilidad Linux: root cambia completamente el incidente
Un usuario limitado puede acceder únicamente a:
- determinados archivos;
- ciertos procesos;
- una aplicación.
Root tiene capacidad mucho mayor sobre el sistema.
Dependiendo de la arquitectura puede intentar:
- modificar servicios;
- leer información;
- instalar persistencia;
- alterar logs;
- capturar credenciales.
Por tanto, una escalada local de privilegios merece prioridad aunque no sea:
remotamente explotable desde Internet.
Vulnerabilidad Linux y servidores cloud
Los servidores Linux son una pieza fundamental de:
☁️ cloud
🌐 web
📦 contenedores
🗄️ bases de datos
⚙️ aplicaciones
💾 NAS y almacenamiento
Por ello, una vulnerabilidad de kernel puede afectar a infraestructuras muy diferentes.
Sin embargo:
cloud ≠ vulnerable automáticamente.
Cada plataforma utiliza:
- versiones distintas;
- kernels diferentes;
- parches específicos.
Hay que verificar.
Vulnerabilidad Linux y sistemas NAS
Numerosos NAS utilizan Linux internamente.
Sin embargo, tampoco debemos asumir que cualquier NAS está afectado.
Los fabricantes pueden:
- usar kernels distintos;
- no incluir el código vulnerable;
- aplicar backports.
Por tanto, ante una CVE de kernel en un NAS:
hay que consultar al fabricante.
No basta con identificar:
“está basado en Linux”.
Vulnerabilidad Linux: no existe evidencia de explotación activa conocida
En el momento de esta revisión, CVE-2026-72018 no aparece en el catálogo KEV de CISA y las fuentes consultadas no muestran evidencia pública de explotación activa generalizada. OpenCVE
Sin embargo, existe algo importante:
XBOW ya ha desarrollado y demostrado un exploit funcional.
Eso cambia el nivel de conocimiento público sobre la viabilidad de explotación. XBOW
Por tanto:
sin explotación activa conocida ≠ podemos ignorarla.
Prueba de concepto y explotación real no son lo mismo
Debemos distinguir:
Vulnerabilidad
El fallo existe.
Exploit de investigación
Se demuestra que puede aprovecharse bajo determinadas condiciones.
Explotación activa
Atacantes están utilizándolo contra organizaciones reales.
Actualmente tenemos evidencia pública sólida de:
las dos primeras.
No deberíamos afirmar la tercera sin evidencias.
Vulnerabilidad Linux y Endpoint / EDR
Un Endpoint / EDR puede aportar una capa adicional para detectar:
- procesos;
- comportamientos;
- scripts;
- escaladas;
- persistencia.
Sin embargo:
EDR no sustituye al parche del kernel.
Una vulnerabilidad conocida debe corregirse.
La estrategia correcta es:
actualización + protección + monitorización.
Vulnerabilidad Linux y firewall
El firewall tampoco soluciona una escalada local de privilegios.
Pero puede:
- reducir accesos iniciales;
- limitar servicios expuestos;
- segmentar;
- registrar conexiones.
Esto demuestra una vez más por qué la ciberseguridad debe trabajar:
por capas.
Puede consultar nuestras soluciones de Endpoint y firewall para empresas.
Vulnerabilidad Linux y SIEM Wazuh
Los servidores Linux son además una de las fuentes que podemos integrar en nuestro servicio de SIEM Wazuh para empresas.
La monitorización puede incluir, dependiendo de la configuración:
- autenticaciones;
- eventos;
- cambios;
- procesos;
- integridad;
- actividad del sistema.
Y puede correlacionarse con:
🔥 firewall
☁️ Microsoft 365
💻 Windows
🍎 macOS
💾 NAS
📡 infraestructura de red
🛡️ Endpoint
Así podemos analizar un incidente desde varias perspectivas.
Vulnerabilidad Linux: el parche corrige, pero no demuestra qué pasó antes
Imagine que hoy actualizamos el kernel.
Perfecto.
Pero todavía existe otra pregunta:
¿alguien aprovechó la vulnerabilidad antes de actualizar?
El parche:
corrige el futuro.
Los logs:
ayudan a investigar el pasado.
Por eso ambos elementos son importantes.
Hasta 400 días de logs para investigación retrospectiva
En nuestros servicios podemos conservar hasta 400 días de histórico de logs de las fuentes integradas.
Esto permite revisar:
- accesos;
- autenticaciones;
- conexiones;
- comportamientos;
- eventos del sistema.
Especialmente cuando una vulnerabilidad se descubre:
meses después de haberse introducido.
Vulnerabilidad Linux y SOC
Wazuh puede:
centralizar + detectar + correlacionar + almacenar.
Nuestro SOC:
analiza los eventos y su contexto.
Porque una alerta de Linux puede corresponder a:
- administración legítima;
- actualización;
- proceso normal;
- error;
- actividad sospechosa.
El contexto determina:
qué significa realmente.
Vulnerabilidad Linux: qué revisar hoy
Una empresa que gestione servidores Linux debería revisar:
1. Distribución
¿Ubuntu, Debian, Red Hat, Amazon Linux u otra?
2. Kernel
¿Qué versión y paquete está instalado?
3. Advisory
¿Qué dice el fabricante sobre CVE-2026-72018?
4. Actualización
¿Existe paquete corregido?
5. Reinicio
¿Estamos ejecutando realmente el kernel nuevo?
6. Contenedores
¿Hay workloads con capabilities innecesarias?
7. CAP_NET_ADMIN
¿Quién la tiene y por qué?
8. Monitorización
¿Disponemos de logs y Endpoint?
Vulnerabilidad Linux y Docker: revisar privilegios de contenedores
En plataformas Docker conviene comprobar especialmente:
- contenedores
--privileged; - capabilities adicionales;
- host networking;
- acceso a sockets;
- montajes del host.
Un contenedor debería disponer únicamente de:
lo necesario para funcionar.
Cada permiso adicional amplía:
su capacidad en caso de compromiso.
Vulnerabilidad Linux y Kubernetes: revisar SecurityContext
En Kubernetes podemos revisar parámetros como:
privileged;allowPrivilegeEscalation;- capabilities;
- hostNetwork;
- hostPID;
- hostPath.
No porque CVE-2026-72018 permita automáticamente explotar Kubernetes.
Sino porque el principio general sigue siendo:
reducir el poder disponible dentro del contenedor.
Vulnerabilidad Linux: root no debería equivaler automáticamente a toda la infraestructura
También necesitamos limitar el impacto incluso si un servidor resulta comprometido.
Para ello podemos utilizar:
- segmentación;
- firewall;
- cuentas separadas;
- MFA;
- claves diferentes;
- mínimo privilegio.
Si obtener root en:
servidor A
permite automáticamente administrar:
servidor B + NAS + backups
la arquitectura necesita revisión.
La segmentación sigue siendo esencial
Un servidor web comprometido no debería tener acceso libre a:
- backups;
- puestos de usuarios;
- administración;
- infraestructura de red.
Por eso las VLAN y reglas internas pueden ayudar a reducir:
movimiento lateral.
De nuevo:
defensa por capas.
Vulnerabilidad Linux: IA y el futuro de la investigación de seguridad
Probablemente esta sea la lección más interesante de CVE-2026-72018.
No es únicamente:
“Linux tenía otro fallo”.
Linux recibe y corrige vulnerabilidades constantemente.
Lo diferente es el método.
Un agente autónomo pudo dedicar:
tiempo de máquina
a una línea de investigación que un especialista podría haber descartado.
Después, investigadores humanos aportaron:
criterio y dirección
en momentos críticos. XBOW
El resultado fue un exploit funcional.
La combinación IA + experto puede ser más importante que IA vs humano
El debate suele plantearse así:
“¿la IA sustituirá al investigador?”
El caso XBOW apunta a algo distinto:
investigador + IA
puede ser mucho más productivo que cualquiera por separado.
La IA puede encargarse de:
- repetición;
- análisis masivo;
- pruebas;
- búsqueda.
El especialista aporta:
- criterio;
- contexto;
- estrategia;
- validación.
Esta combinación probablemente será cada vez más habitual.
Vulnerabilidad Linux: conclusión
La vulnerabilidad Linux CVE-2026-72018 es una escritura fuera de límites en la implementación DIBS loopback del kernel.
Está clasificada como:
CVSS 7.8 — Alta
y puede utilizarse para una escalada local de privilegios con impacto potencial sobre confidencialidad, integridad y disponibilidad. Ubuntu
La investigación de XBOW resulta especialmente relevante porque su agente de IA llevó a cabo buena parte del:
modelado + auditoría + descubrimiento + validación + desarrollo del exploit, aunque investigadores humanos tuvieron que intervenir en momentos decisivos. XBOW
El hallazgo convirtió una primitiva aparentemente limitada de:
16 bytes
en:
root.
Sin embargo, tampoco debemos convertir el caso en algo que no es.
❌ No es una vulnerabilidad remota desde cualquier equipo de Internet.
❌ No significa que todos los servidores Linux estén afectados.
❌ No significa que cualquier contenedor Docker pueda escapar automáticamente.
❌ No existe evidencia pública de explotación activa generalizada en este momento. OpenCVE
Lo correcto es:
✅ identificar la distribución y kernel
✅ consultar el advisory del fabricante
✅ instalar la actualización correspondiente
✅ reiniciar cuando sea necesario
✅ revisar capabilities en contenedores
✅ aplicar mínimo privilegio
✅ monitorizar servidores
✅ conservar logs para investigaciones posteriores
En GHM Soluciones Informáticas trabajamos con:
🐧 Linux
🖥️ servidores
🔥 firewall
🛡️ Endpoint / EDR
📊 SIEM Wazuh
🔎 análisis SOC
🗄️ hasta 400 días de histórico de logs
Porque el descubrimiento de una vulnerabilidad no debería desencadenar únicamente:
“instala el parche”.
También debería generar dos preguntas:
¿tenemos sistemas afectados?
y:
¿podríamos saber qué ocurrió antes de corregirlos?
📩 Contactar con GHM Soluciones Informáticas
Preguntas frecuentes sobre la vulnerabilidad Linux CVE-2026-72018
¿Qué es CVE-2026-72018?
Es una vulnerabilidad de escritura fuera de límites en el subsistema DIBS loopback del kernel de Linux. GitHub
¿Qué gravedad tiene?
Su puntuación es CVSS 7.8 — Alta. No está clasificada como crítica. Ubuntu
¿Puede proporcionar acceso root?
XBOW desarrolló una explotación local que consiguió escalar privilegios hasta root bajo determinadas condiciones. XBOW
¿La vulnerabilidad es remota?
No. El vector CVSS oficial es local. GitHub
¿Necesita interacción del usuario?
El vector CVSS indica que no requiere interacción del usuario.
¿Qué componente está afectado?
La implementación DIBS loopback utilizada por SMC-D.
¿Qué significa SMC-D?
Shared Memory Communications Direct, un mecanismo relacionado con comunicaciones mediante memoria compartida.
¿Qué cambió con DIBS?
Permitió que determinadas rutas SMC-D pudieran ejecutarse sobre sistemas Linux x86 convencionales mediante un dispositivo virtual loopback. XBOW
¿Quién descubrió la vulnerabilidad?
La investigación fue realizada por XBOW mediante su plataforma autónoma de seguridad, con intervención humana en determinados momentos importantes. XBOW
¿La IA realizó todo el descubrimiento sola?
No. XBOW indica que el agente hizo gran parte del trabajo, pero hubo intervenciones humanas decisivas.
¿Qué tiene de especial la escritura de 16 bytes?
XBOW consiguió transformar una primitiva muy limitada de escritura en memoria en una escalada local completa hasta root. XBOW
¿Necesita CAP_NET_ADMIN?
La prueba de explotación publicada por XBOW utilizó CAP_NET_ADMIN para manipular tráfico loopback, aunque el registro CVE clasifica los privilegios requeridos como bajos. XBOW
¿Afecta a Docker?
Puede ser relevante para entornos de contenedores porque comparten el kernel del host, pero la explotación depende de versión, configuración y capabilities. No implica un escape automático.
¿Afecta a Kubernetes?
Puede ser relevante para nodos que ejecuten kernels vulnerables, pero no significa que cualquier pod pueda explotar automáticamente el fallo.
¿Debería retirar Docker?
No. La recomendación es corregir el kernel y aplicar controles adecuados sobre privilegios y capabilities.
¿Son más seguras las máquinas virtuales?
Ofrecen una frontera de aislamiento diferente porque normalmente ejecutan su propio kernel, aunque también pueden tener vulnerabilidades.
¿Qué versiones están corregidas?
Las referencias del kernel recogen correcciones en distintas ramas, entre ellas 6.12.97, 6.18.40, 7.1.5 y 7.2. OpenCVE
¿Tengo que comparar directamente mi versión con esas cifras?
No necesariamente. Los fabricantes pueden aplicar backports. Debe consultarse el advisory de la distribución.
¿Ubuntu está afectado?
Depende de la release y del paquete de kernel. Canonical publica estados distintos según versión. Ubuntu
¿Debian está afectado?
También depende de la versión. Debian mantiene información detallada sobre paquetes afectados y corregidos. Security Tracker
¿Amazon Linux está afectado?
Las ramas actuales indicadas por Amazon en su advisory aparecen como no afectadas, aunque conviene comprobar siempre el sistema concreto. Explora Alas
¿Existe explotación activa?
No consta actualmente en CISA KEV ni existe evidencia pública de explotación activa generalizada en las fuentes revisadas. OpenCVE
¿Existe un exploit?
XBOW afirma haber desarrollado y validado una escalada local funcional hasta root. XBOW
¿Qué debe hacer una empresa?
Consultar el aviso de su distribución, actualizar el kernel, reiniciar cuando corresponda, verificar la versión activa y revisar permisos de contenedores.
¿Qué aporta SIEM Wazuh?
Permite centralizar y correlacionar eventos de Linux con información de firewall, endpoints, Microsoft 365 y otras fuentes.
¿Qué aporta nuestro SOC?
Nuestro SOC analiza los eventos y su contexto para diferenciar actividad legítima, anomalías y situaciones que requieren investigación.
¿Por qué conservar hasta 400 días de logs?
Porque una vulnerabilidad puede descubrirse meses después de que un sistema haya estado expuesto y puede ser necesario realizar una investigación retrospectiva.
¿Cuál es la principal lección de CVE-2026-72018?
La inteligencia artificial puede permitir investigar con mucha más profundidad vulnerabilidades aparentemente poco prometedoras, mientras que las empresas necesitan acelerar inventario, parcheado, mínimo privilegio y monitorización para reducir su exposición.
La investigación técnica original de XBOW explica cómo se identificó el fallo y cómo una escritura limitada terminó convirtiéndose en una escalada local de privilegios. XBOW
Investigación técnica de XBOW sobre CVE-2026-72018
Estado de CVE-2026-72018 en Ubuntu
Seguimiento de CVE-2026-72018 en Debian
