El proyecto MDASH del FORGE Lab combinó agentes de IA con investigadores humanos para encontrar vulnerabilidades en el kernel, pero validar y patchear cada hallazgo requirió cuatro meses de trabajo manual.
Un proyecto de investigación de Microsoft identificó 59 vulnerabilidades en el kernel de Linux mediante una combinación de agentes de IA y validación humana, incluyendo fallas que habían permanecido en código de producción durante más de dos décadas. El hallazgo más antiguo, CVE-2026-74544, estuvo presente en el kernel durante al menos 21 años antes de ser reportado públicamente el 27 de junio de 2026. La edad promedio de las vulnerabilidades descubiertas fue de 8.1 años al momento del primer reporte público.
El proyecto, conducido por el FORGE Lab de Microsoft bajo el nombre clave MDASH, escaneó componentes seleccionados del kernel que incluyen networking, filesystems y módulos de seguridad. En aproximadamente dos semanas de escaneo automatizado, el sistema generó 26,502 hallazgos potenciales. De ese volumen inicial, 33 vulnerabilidades recibieron asignación de CVE, y 24 de ellas obtuvieron calificación High o superior según CVSS v3.1, con puntajes de al menos 7.0.
Cómo 26,502 alertas automatizadas se redujeron a 59 reportes verificados
El proceso de filtrado comenzó con un screening automatizado que redujo los hallazgos iniciales a 11,767 candidatos. Agentes de IA intentaron reproducir las vulnerabilidades potenciales usando QEMU, un emulador de máquina de código abierto, lo que produjo 621 casos con evidencia de proof-of-concept. Investigadores humanos revisaron estos casos para identificar causas raíz, fusionar duplicados y preparar las submisiones upstream.
De los 621 casos con evidencia de PoC, 59 resultaron en reportes públicos upstream. Otros 266 hallazgos compartían causas raíz con otros casos y podían ser resueltos mediante el mismo parche. Microsoft no reportó 163 hallazgos adicionales tras revisión, principalmente por impacto de seguridad limitado, mientras que 133 ya habían sido reportados o corregidos upstream antes de que el equipo completara su análisis.
Para 55 de los 59 reportes, Microsoft publicó la información en listas de correo públicas antes del 1 de septiembre de 2026. Los cuatro restantes fueron reportados de forma privada durante el mismo período y redirigidos a listas públicas a mediados de octubre. El equipo desarrolló exploits funcionales de escalada de privilegios raíz para ocho de las vulnerabilidades asignadas con CVE.
CVE-2026-64563: cuando un cambio de código de 2018 abre una vía de escalada sin privilegios
Una de las vulnerabilidades con exploit funcional, CVE-2026-64563, involucra la implementación rhashtable del kernel, una biblioteca compartida de tabla hash redimensionable utilizada por diferentes subsistemas del kernel. Microsoft rastreó la falla hasta un cambio de código introducido en 2018 que permitía a una operación de table-walk retener un puntero cuando se pausaba. Bajo condiciones específicas que involucran el redimensionamiento de la tabla y la eliminación de una entrada, el kernel podía acceder posteriormente a memoria liberada a través de ese puntero obsoleto.
Los investigadores identificaron una ruta explotable a través de diagnósticos de socket Netlink, que son accesibles para usuarios sin privilegios. Mediante manipulación de memoria, un atacante podría convertir la falla en una primitiva de escritura de memoria del kernel con restricciones que, combinada con otras técnicas de explotación, podría habilitar escalada de privilegios local. Microsoft señaló que esta vulnerabilidad era explotable en configuraciones estándar de Linux sin requerir configuraciones especiales del kernel ni user namespaces, y que también afectaba dispositivos Android con SELinux enforcing.
Por qué el patching sigue siendo un cuello de botella humano pese a la automatización
Aunque los agentes de IA ayudaron a identificar vulnerabilidades potenciales, generar demostraciones de proof-of-concept y redactar parches iniciales, Microsoft indicó que la investigación humana siguió siendo necesaria para validar hallazgos y trabajar con los maintainers del kernel de Linux. El proceso upstream de Linux típicamente requiere que los reportes de vulnerabilidades vengan acompañados de un parche funcional. Los agentes ayudaron a redactar correcciones iniciales, pero la validación humana, la comprensión del subsistema y la iteración con maintainers durante la revisión permanecieron como tareas esenciales.
Al momento de publicación del proyecto, los parches para 38 de los 59 reportes habían sido fusionados en el mainline upstream de Linux. La mitad fueron aceptados con la submisión inicial, mientras que los otros requirieron entre una y cuatro revisiones. El tiempo mediano desde la primera submisión pública del parche hasta un release mainline fue de 41 días, con el caso más largo tomando 108 días. El trabajo con maintainers sobre los reportes restantes continuaba en curso.
Microsoft señaló que los escaneos iniciales tomaron aproximadamente dos semanas, pero convertir los hallazgos en reportes validados y parches requirió más de cuatro meses-persona de trabajo. Los investigadores indicaron que encontrar bugs y corregirlos están drásticamente fuera de balance, y que para infraestructura compleja como el kernel de Linux, mantener humanos en el loop sigue siendo necesario, haciendo del esfuerzo humano el cuello de botella del proceso.
Exposición en América Latina por dependencia de Android y distribuciones enterprise
La vulnerabilidad CVE-2026-64563, explotable en dispositivos Android con SELinux enforcing, representa un vector de riesgo concreto para América Latina, donde Android mantiene más del 80 por ciento de participación de mercado móvil en países como Brasil, México, Argentina y Colombia. La accesibilidad de la falla a usuarios sin privilegios mediante sockets Netlink implica que aplicaciones maliciosas instaladas en dispositivos Android podrían escalar privilegios localmente sin requerir configuraciones especiales del kernel.
Para infraestructura enterprise en la región, la edad promedio de 8.1 años de las vulnerabilidades descubiertas plantea una pregunta sobre el ciclo de actualización de distribuciones de soporte extendido. Organizaciones en sectores regulados de Brasil, Chile y México que operan sobre versiones LTS de distribuciones enterprise podrían estar ejecutando código con fallas introducidas hace más de una década, especialmente en componentes de networking y filesystems que fueron parte del alcance del escaneo de Microsoft. Esto no es un dato reportado sobre exposición específica en LATAM, sino una lectura de contexto estructural basada en la prevalencia regional de Android y el uso documentado de distribuciones LTS en sectores financiero y gubernamental.
Nuestro análisis
El proyecto MDASH revela una asimetría operativa que ya se había documentado en investigaciones previas sobre fuzzing automatizado: la capacidad de generar hallazgos potenciales escala exponencialmente con recursos computacionales, pero la capacidad de validar, patchear y fusionar correcciones upstream permanece anclada a ritmos humanos. Microsoft generó 26,502 hallazgos en dos semanas de escaneo, pero requirió cuatro meses-persona para convertir 59 de esos hallazgos en reportes upstream con parches funcionales. Esa proporción — aproximadamente 450 hallazgos iniciales por cada reporte validado — sugiere que el cuello de botella no está en la detección sino en la capacidad de procesamiento downstream.
La presencia de CVE-2026-74544 en el kernel durante 21 años, y la edad promedio de 8.1 años para el conjunto de vulnerabilidades descubiertas, plantea una pregunta sobre qué otros bugs de larga data permanecen sin detectar en código de producción ampliamente auditado. El proyecto escaneó solo una fracción seleccionada del kernel de Linux — componentes de networking, filesystems y módulos de seguridad — lo que deja sin cubrir subsistemas completos. Microsoft indicó que ajustes adicionales del enfoque asistido por IA podrían descubrir más bugs, pero advirtió que encontrar más vulnerabilidades no necesariamente hace a los sistemas más seguros. La pregunta que queda abierta es si la industria tiene capacidad de absorber un volumen mayor de reportes de vulnerabilidades sin colapsar los procesos de revisión y patching que ya operan con tiempos medianos de 41 días desde submisión hasta release mainline.