![[Joan Alonso Design] Diseño gráfico y Web](https://joanalonsodesign.es/wp-content/uploads/2023/01/Logo-JoanAlonsoDesign-1.png){kind=logo}
Una plataforma de investigación de seguridad asistida por inteligencia artificial ha descubierto y conseguido validar una vulnerabilidad del kernel de Linux que puede utilizarse para elevar privilegios hasta root. El fallo, identificado como CVE-2026-72018, afecta al subsistema SMC-D y, más concretamente, a su implementación de loopback DIBS.
Lo interesante no es solo la vulnerabilidad. El caso muestra hasta dónde puede llegar una IA cuando se utiliza para revisar código de bajo nivel durante periodos prolongados y, al mismo tiempo, dónde sigue siendo importante el criterio humano. XBOW, la plataforma que publicó la investigación, explica que su sistema encontró el problema, lo validó y desarrolló una prueba de escalada de privilegios, pero también reconoce varias intervenciones humanas decisivas durante el proceso. La investigación técnica de XBOW fue publicada a finales de septiembre de 2026.
Por tanto, no estamos ante la idea simplista de que una IA “ha hackeado Linux” por sí sola. El caso resulta más interesante: una IA fue capaz de encontrar valor de seguridad en un fallo que inicialmente parecía demasiado limitado para convertirse en una escalada de privilegios útil.
Qué ha descubierto exactamente la IA
CVE-2026-72018 es una vulnerabilidad de tipo out-of-bounds write, es decir, una escritura fuera de los límites de una zona de memoria reservada. El problema se encuentra en la función move_data() de la implementación dibs_loopback del kernel.
El código recibía determinados valores relacionados con el desplazamiento y el tamaño de los datos y terminaba realizando una copia de memoria sin comprobar correctamente que la operación permaneciera dentro de los límites del búfer. En el hardware real que históricamente utilizaba SMC-D existen mecanismos que impiden este tipo de acceso fuera de la región asignada. La implementación de loopback, al realizar esas operaciones por software, no contaba con una comprobación equivalente.
El resultado es una condición en la que datos controlados por el extremo de la comunicación pueden provocar una escritura más allá del búfer previsto. La descripción oficial de Ubuntu confirma que el problema se resolvió añadiendo una comprobación explícita antes de la copia de memoria. Ubuntu documenta el CVE-2026-72018 con una puntuación CVSS de 7,8, considerada alta en su evaluación de severidad.
Por qué el fallo está en una parte poco conocida de Linux
Para entender por qué esta vulnerabilidad había pasado desapercibida conviene detenerse en SMC-D. Se trata de una tecnología relacionada con Shared Memory Communications, diseñada para permitir determinadas comunicaciones entre sistemas utilizando memoria compartida.
Durante años, buena parte de este código estuvo asociado a entornos IBM Z y a hardware específico. Eso hacía que algunas rutas del código resultaran mucho menos habituales en un ordenador Linux convencional. La situación cambió con la introducción de DIBS y de un dispositivo de loopback que permite ejecutar determinadas rutas de SMC-D sin disponer del hardware original.
Ese cambio tiene una consecuencia de seguridad importante: una superficie que antes estaba condicionada por un entorno de hardware concreto pasa a estar disponible en máquinas x86 normales. El código antiguo no necesariamente cambia al mismo ritmo que cambia su contexto de ejecución.
Esta es una de las lecciones más interesantes del caso. Una función puede parecer poco relevante porque históricamente ha tenido una exposición muy limitada y convertirse en una superficie de ataque diferente cuando aparece una nueva vía para utilizarla.
Una comprobación de límites ausente permitió una escritura fuera del búfer en DIBS loopback.
El detalle que parecía demasiado pequeño para ser importante
La investigación de XBOW tiene una particularidad especialmente llamativa. La vulnerabilidad no proporcionaba inicialmente una capacidad espectacular. Según el equipo de investigación, la primitiva que consiguieron obtener en el escenario local era extremadamente limitada: una escritura de 16 bytes de ceros en una posición controlada.
Para un investigador humano que analiza decenas o cientos de posibles errores del kernel, una primitiva tan restringida puede parecer poco prometedora. El tiempo necesario para convertirla en una escalada de privilegios puede no compensar el esfuerzo, especialmente si existen otros candidatos más evidentes.
Ahí aparece una diferencia importante entre una auditoría convencional y un sistema automatizado capaz de dedicar mucho tiempo a una misma línea de investigación. XBOW siguió explorando el problema en lugar de descartarlo simplemente porque la capacidad inicial pareciera débil.
La empresa explica que su sistema tuvo que analizar el código, revisar diferentes hipótesis y probar cómo podía utilizarse la escritura limitada. El resultado fue una escalada de privilegios local hasta root sin necesitar combinar la vulnerabilidad con otra fuga de información independiente.
Qué significa “llegar a root” en este contexto
En Linux, root es la cuenta con el nivel de privilegio más alto del sistema. Una vulnerabilidad que permita a un usuario con pocos privilegios convertirse en root cambia de forma radical el impacto potencial de un fallo local.
Una vez alcanzado ese nivel, el atacante puede acceder a recursos que normalmente están protegidos frente a usuarios ordinarios, modificar configuraciones, interferir con procesos del sistema y comprometer la separación entre aplicaciones y servicios que dependen del mismo núcleo.
Eso no significa que CVE-2026-72018 sea una vulnerabilidad que permita tomar el control de cualquier servidor Linux simplemente enviándole una petición desde Internet. El vector indicado por las evaluaciones de seguridad es local y requiere privilegios bajos. Ubuntu publica para el CVE un vector CVSS con AV:L, PR:L y sin interacción del usuario.
Esta diferencia es fundamental. “Puede llegar a root” describe el impacto de una escalada de privilegios; no significa necesariamente “permite entrar remotamente en cualquier servidor”.
El papel de la inteligencia artificial fue más complejo de lo que parece
La parte más interesante de esta historia quizá no sea la vulnerabilidad, sino la forma en que fue encontrada. XBOW describe una campaña prolongada de análisis en la que su sistema realizó buena parte del trabajo de lectura de código, modelado de amenazas, validación y desarrollo de la explotación.
Sin embargo, la propia investigación deja claro que hubo decisiones humanas relevantes. En determinados momentos el sistema había descartado caminos que después resultaron importantes. Los investigadores humanos redirigieron la investigación, hicieron que la IA comprobara experimentalmente algunas de sus suposiciones y la orientaron hacia el aprovechamiento de la primitiva que ya tenía.
XBOW identifica tres intervenciones humanas principales durante esa investigación. La primera consistió en recuperar una hipótesis que el sistema había abandonado. La segunda fue obligarlo a volver a comprobar qué capacidad proporcionaba realmente la primitiva de memoria. La tercera consistió en evitar que buscara una vulnerabilidad adicional más sofisticada cuando ya existía una vía suficiente para demostrar la escalada.
Por eso resulta más preciso hablar de investigación de vulnerabilidades asistida y automatizada por IA que de una IA trabajando de manera completamente autónoma desde el primer momento.
Qué tiene de nuevo este caso para la seguridad informática
La revisión automatizada de código no es nueva. En este contexto resulta útil recordar cómo está cambiando la IA el panorama de la ciberseguridad, aunque el caso de CVE-2026-72018 pertenece a un problema técnico diferente. Desde hace años existen analizadores estáticos, fuzzers, sistemas de detección de errores y herramientas capaces de recorrer enormes cantidades de código.
La diferencia está en combinar esas capacidades con modelos capaces de razonar sobre el contexto del código, plantear hipótesis y continuar una investigación durante mucho más tiempo. El valor potencial no consiste únicamente en encontrar un error, sino en decidir si ese error merece seguir investigándose y buscar una forma de demostrar su impacto.
CVE-2026-72018 es un buen ejemplo porque el primer resultado parecía poco útil. La escritura estaba muy restringida y el camino hasta una escalada de privilegios no era evidente. Una herramienta que solo buscara errores obvios podría haber clasificado el hallazgo como poco interesante.
En cambio, una IA capaz de mantener una investigación técnica durante muchas iteraciones puede explorar posibilidades que un investigador humano quizá descartaría por coste de tiempo. Esa capacidad no garantiza encontrar vulnerabilidades, pero puede cambiar la economía de la investigación de seguridad.
El riesgo para servidores, contenedores e infraestructura de IA
El hecho de que el fallo sea local hace que su contexto sea especialmente importante. Una escalada de privilegios de este tipo puede convertirse en un segundo paso dentro de una intrusión que ya ha conseguido acceso limitado al sistema.
El escenario es relevante en servidores multiusuario, máquinas virtuales, estaciones de trabajo y determinadas infraestructuras que ejecutan cargas de trabajo aisladas. También merece atención en entornos de inteligencia artificial, donde grandes cantidades de software y servicios pueden ejecutarse sobre Linux.
En sistemas basados en contenedores, además, el kernel es compartido por las cargas que se ejecutan sobre el mismo host. Eso no significa que CVE-2026-72018 permita automáticamente escapar de cualquier contenedor, pero sí explica por qué las vulnerabilidades de escalada en el kernel reciben una atención especial en infraestructuras donde el aislamiento depende de él.
La consecuencia práctica es sencilla: los contenedores no deben considerarse una razón para retrasar las actualizaciones del kernel del host. La seguridad de la capa de virtualización o aislamiento depende también de la seguridad del núcleo que la sostiene.
¿Qué versiones de Linux están afectadas?
La respuesta no puede reducirse a una lista universal de distribuciones porque cada fabricante integra y mantiene sus propios paquetes del kernel. Además, las distribuciones suelen incorporar correcciones mediante backports, por lo que el número de versión que aparece en una máquina no siempre permite determinar por sí solo si un fallo está corregido.
La documentación del CVE sitúa el problema en versiones del kernel afectadas por el código vulnerable de DIBS loopback. Ubuntu, por ejemplo, indicaba a fecha de 22 de septiembre de 2026 que Ubuntu 26.04 LTS estaba todavía en estado “Vulnerable, work in progress” para el paquete principal, mientras que otras versiones LTS figuraban como no afectadas o con estados diferentes según el paquete y el kernel utilizado.
Red Hat también advierte de que sus puntuaciones y estados dependen del producto concreto y de cómo se distribuye el kernel. En sus sistemas, además, es habitual incorporar correcciones mediante backport sin cambiar completamente la versión principal del paquete.
Por eso, la comprobación correcta no consiste en buscar simplemente “Linux 6.x” en una tabla genérica. Hay que consultar el aviso de seguridad de la distribución concreta y comprobar el paquete instalado y su estado de actualización.
La corrección ya existe: qué debería hacer un administrador
El problema fue comunicado a los mantenedores del kernel en junio de 2026. XBOW indica que el parche fue aprobado en julio y que el CVE se hizo público en agosto.
La corrección consiste en validar los límites antes de realizar la copia de memoria. En otras palabras, el kernel debe comprobar que la combinación de desplazamiento y tamaño no sobrepasa la longitud del búfer antes de ejecutar la operación.
Para un administrador, la recomendación no es aplicar manualmente fragmentos de código del kernel, sino utilizar las actualizaciones de seguridad proporcionadas por la distribución. Ubuntu, Debian, Red Hat y otros mantenedores pueden integrar la corrección en paquetes diferentes y en fechas distintas.
También conviene recordar una regla básica de seguridad: un servidor que no necesita una determinada funcionalidad no debería mantenerla habilitada sin una razón operativa. Reducir la superficie de ataque sigue siendo útil, pero en este caso no sustituye a la actualización del kernel cuando el sistema está afectado.
El caso muestra una colaboración entre automatización de IA y criterio humano durante una investigación prolongada.
Qué nos dice este caso sobre la IA como herramienta de ciberseguridad
La historia de CVE-2026-72018 encaja en una tendencia más amplia: los modelos de IA están empezando a utilizarse para analizar código de sistemas, buscar errores y automatizar partes de la investigación de vulnerabilidades.
Eso puede aportar una ventaja evidente: una IA no necesita decidir que un fragmento de código es “demasiado aburrido” para dedicarle otra hora. Puede recorrer funciones, relacionar estructuras y repetir hipótesis a una escala difícil de mantener manualmente.
Pero el caso también muestra el límite. Los propios investigadores describen momentos en los que el sistema abandonó hipótesis válidas, confundió supuestos anteriores o necesitó una intervención humana para cambiar de dirección. La automatización, por tanto, no elimina la necesidad de metodología, revisión y criterio.
Para los defensores ocurre algo parecido. También puede resultar útil el análisis sobre agentes de inteligencia artificial y los controles que necesitan, porque ayuda a entender la diferencia entre automatización y autonomía real. La IA puede ayudar a revisar código, clasificar alertas, analizar configuraciones o priorizar vulnerabilidades, pero una organización sigue necesitando controles independientes que permitan comprobar qué ha encontrado el sistema y qué consecuencias reales tiene.
Una consecuencia importante: la superficie de ataque también evoluciona
Quizá la lección más útil del caso no sea “la IA encuentra vulnerabilidades”. Es otra: la superficie de ataque cambia cuando cambia la forma de utilizar una tecnología.
El código de SMC-D podía parecer poco expuesto cuando dependía de hardware especializado. La aparición de una implementación de loopback modificó ese supuesto. De repente, parte de ese código podía ejecutarse en máquinas Linux convencionales y merecía ser revisado con un modelo de amenaza distinto.
Esta situación se repite en muchos sistemas complejos. Un componente que originalmente estaba pensado para un entorno muy concreto puede acabar expuesto mediante una nueva capa de abstracción, una virtualización, un driver, una API o una función de compatibilidad.
La seguridad no consiste únicamente en comprobar si una función contiene errores. También hay que revisar quién puede llegar hasta ella, en qué condiciones y qué cambió desde que fue diseñada.
Conclusión: el verdadero cambio está en la economía de descubrir fallos
CVE-2026-72018 es un fallo serio del kernel de Linux porque una escritura fuera de límites en el subsistema DIBS loopback puede convertirse en una escalada local de privilegios hasta root. La corrección pasa por validar adecuadamente los límites de la operación de memoria y por mantener los kernels de las distribuciones actualizados.
Sin embargo, el aspecto más novedoso de este caso está en cómo se descubrió. XBOW utilizó una IA para recorrer código, investigar una vulnerabilidad inicialmente poco prometedora y demostrar que una primitiva muy limitada podía tener un impacto mucho mayor del esperado.
Al mismo tiempo, la investigación demuestra que todavía existe una diferencia entre automatizar muchas tareas y sustituir completamente el criterio de un investigador experimentado. Las intervenciones humanas fueron importantes para cambiar el rumbo de la investigación y corregir supuestos equivocados.
Para empresas y administradores, la conclusión práctica es menos futurista: mantener el kernel actualizado, conocer qué distribución y paquetes se están utilizando y no asumir que un componente poco conocido es irrelevante para la seguridad. Para el sector de la ciberseguridad, en cambio, este caso apunta a un cambio más profundo: la IA puede reducir el coste de investigar vulnerabilidades que antes no compensaba explorar.
Si trabajas con servidores, WordPress o infraestructura web, esta misma lógica se aplica a todo el ecosistema. En proyectos WordPress conviene además revisar periódicamente la seguridad de plugins, temas y dependencias de terceros. no basta con proteger la aplicación visible. También hay que mantener actualizados el sistema operativo, el servidor web, las dependencias y los componentes que forman la base técnica del proyecto.
Preguntas frecuentes sobre CVE-2026-72018
¿La vulnerabilidad permite atacar cualquier servidor Linux desde Internet?
No. Las evaluaciones publicadas la clasifican como una vulnerabilidad de vector local y con privilegios bajos requeridos. Su impacto principal es la escalada de privilegios dentro de un sistema que ya ofrece al atacante una posición local suficiente para alcanzar la ruta vulnerable.
¿La IA descubrió por sí sola la vulnerabilidad?
XBOW atribuye a su plataforma el descubrimiento, la validación y el desarrollo de la escalada, pero su propio informe describe varias intervenciones humanas decisivas. Por eso es más preciso hablar de investigación automatizada o asistida por IA que de un proceso completamente independiente del principio al final.
¿Qué CVE corresponde al fallo?
El identificador es CVE-2026-72018. Está asociado a una escritura fuera de límites en la implementación DIBS loopback del subsistema SMC-D del kernel de Linux.
¿Hay que cambiar de distribución de Linux?
No. La respuesta adecuada depende del estado del paquete de kernel que utiliza cada distribución. Lo importante es comprobar el aviso de seguridad correspondiente y aplicar la actualización que incorpore la corrección.
¿Qué relación tiene el fallo con la inteligencia artificial?
La vulnerabilidad no fue causada por una IA. La relación está en su descubrimiento: XBOW utilizó una plataforma de investigación automatizada basada en IA para analizar el código y convertir un error inicialmente poco prometedor en una demostración de escalada de privilegios.
