Un fuzzer de IA listo para usar encuentra siete fallos en FatFs, integrado en millones de dispositivos

¿Qué es esto?

El 1 de julio de 2026, la firma de seguridad runZero divulgó siete vulnerabilidades en FatFs, una pequeña biblioteca en C que permite a los dispositivos embebidos leer y escribir los formatos FAT y exFAT usados por memorias USB y tarjetas SD. FatFs no es una pieza marginal: está integrada en el firmware de cámaras de seguridad, drones, controladores industriales, carteras de hardware de criptomonedas e incontables sistemas de tiempo real. En los dispositivos más afectados, un volumen de almacenamiento o una imagen de firmware manipulados pueden corromper la memoria y ejecutar código del atacante — y como muchos chips embebidos carecen de las protecciones de memoria de los teléfonos y PC, runZero resume el impacto sin rodeos: «cualquier acceso físico conduce a un jailbreak».

Los bugs en sí son errores habituales de seguridad de memoria. Lo que hace interesante esta divulgación es cómo se encontraron. runZero ya había auditado FatFs a mano en 2017 sin apenas nada que reportar. Al regresar en marzo de 2026, el equipo apuntó al mismo código un montaje casi enteramente listo para usar — Visual Studio Code, GitHub Copilot en modo «auto» y unos pocos prompts sencillos — y dejó que el modelo construyera un fuzzer. Ese arnés hizo aflorar bugs que la auditoría humana había pasado por alto, y ayudó a confirmar que eran alcanzables.

Cómo funciona

Un fuzzer es una herramienta que inyecta datos malformados en un programa hasta que algo se rompe. Escribir uno bueno para un analizador de sistemas de archivos suele exigir un trabajo real: hay que comprender las estructuras en disco, generar imágenes de disco mutadas y montar un arnés capaz de montarlas y capturar los fallos. Aquí el LLM produjo esa infraestructura a partir de prompts en lenguaje natural, y el fuzzer resultante exploró el código de análisis con más profundidad que una revisión manual puntual.

Cada uno de los siete hallazgos sigue el mismo patrón. El dispositivo intenta leer un volumen de almacenamiento o una imagen de actualización deliberadamente corrompidos, y FatFs maneja mal los datos. El problema estrella es un desbordamiento de entero en el código que monta un volumen FAT32: una aritmética errónea produce un tamaño de archivo falso, que el código posterior trata como una longitud de lectura real — en hardware real, eso puede convertirse en corrupción de memoria y ejecución de código. Los demás incluyen un campo de etiqueta de volumen exFAT que desborda un búfer pequeño, nombres de archivo largos que desbordan el código envoltorio que muchos proyectos colocan alrededor de FatFs, un desbordamiento de cálculo en la gestión de caché que corrompe silenciosamente los datos en volúmenes fragmentados, una división por cero de exFAT que puede «ladrillar» el hardware durante una actualización, y una lectura más allá del final que filtra bytes residuales de archivos previamente eliminados. runZero clasificó el conjunto de CVSS Medio a Alto, sin ningún Crítico, y publicó imágenes de disco de demostración y un arnés de prueba basado en QEMU en un repositorio público de acompañamiento, para que los fabricantes puedan reproducir y verificar las correcciones.

runZero es explícito: no se trata de un golpe aislado. El mismo patrón lleva más de un año dibujándose: el agente Big Sleep de Google encontró a finales de 2024 un bug de memoria real y explotable en SQLite que el fuzzing tradicional había pasado por alto, y en junio de 2026 un agente autónomo hizo aflorar 21 bugs de seguridad de memoria en FFmpeg, otra biblioteca en C ampliamente embebida. El mensaje del equipo: si un pipeline de IA casi listo para usar puede encontrar estos fallos, cualquiera puede.

Por qué importa

Dos cosas cambiaron aquí, y solo una es el código. La primera es la economía del descubrimiento. Auditar un analizador en C de décadas de antigüedad exigía el tiempo y la paciencia de un especialista; ahora un desarrollador con un asistente de código de consumo puede levantar un arnés de fuzzing eficaz en una tarde. Eso baja el listón para los defensores — y por igual para los atacantes, que ya no necesitan una experiencia profunda en sistemas de archivos para salir a buscar el próximo FatFs.

La segunda es el circuito de divulgación, que no ha escalado con el descubrimiento. FatFs lo mantiene un único desarrollador, y runZero afirma haber intentado repetidamente contactarlo e implicó al centro de coordinación JPCERT/CC de Japón, sin respuesta. En consecuencia, no hay corrección upstream para los bugs de corrupción de memoria, ni lista de correo de seguridad, ni canal para avisar a los muchos productos que integran FatFs de que están expuestos. Solo uno de los siete — una denegación de servicio por tabla de particiones malformada — está corregido upstream, en la versión R0.16. Todo lo demás recae en los fabricantes aguas abajo, que deben corregirlo por su cuenta. runZero nombra plataformas afectadas como Espressif ESP-IDF, STMicroelectronics STM32Cube, Zephyr, MicroPython, ArduPilot, RT-Thread, Mbed, Samsung TizenRT y el actualizador SWUpdate — lo que propaga el problema al IoT de consumo, los equipos industriales, los drones y las carteras de hardware. El precedente que cita runZero es PixieFail, un lote de fallos de firmware de 2024 que los fabricantes tardaron en corregir; FatFs tiene la misma forma y un circuito de corrección más débil, por falta de un upstream receptivo. A la fecha de la divulgación, no se habían reportado ataques.

Defensas

La lección incómoda es que «nadie se molestó en mirar» ya no es una defensa, porque mirar se ha vuelto barato. Tanto constructores como operadores tienen palancas concretas.

Si distribuye firmware que toca soportes FAT o exFAT, localice la copia de FatFs en su producto y trátela como un analizador no confiable que maneja entradas controladas por el atacante. Audite el código envoltorio que la rodea — los patrones tipo strcpy hacia un búfer fijo son precisamente donde varios de estos bugs aterrizan — y examine con atención cómo calcula nombres y tamaños de archivo. Incorpore la versión upstream R0.16 para la corrección de la tabla de particiones, y retroporte o mitigue usted mismo los problemas de corrupción de memoria, dado que no existe parche upstream. Donde el hardware lo permita, active las protecciones de memoria (regiones MPU/MMU, canarios de pila, W^X) para que un bug de análisis sea un fallo y no un jailbreak. Considere lanzar su propia pasada de fuzzing asistida por IA contra la build exacta de FatFs y el envoltorio que distribuye; las mismas herramientas de consumo que encontraron estos bugs pueden encontrar los siguientes antes que un atacante.

Si opera dispositivos afectados, trate los puertos físicos y los canales de actualización de firmware como una superficie de ataque, no como una comodidad. Limite quién puede insertar soportes en quioscos, cámaras, cajeros y controladores; valide y firme las imágenes de firmware para que no pueda forzarse una actualización malformada; y vigile los parches del fabricante, entendiendo que para una dependencia huérfana como esta pueden tardar años en llegar.

Estado

Referencia (runZero, 1 de julio de 2026)	CVSS	Efecto
CVE-2026-6682	7.6 (Alto)	Desbordamiento de entero al montar FAT32 → corrupción de memoria, posible ejecución de código; alcanzable vía ciertas actualizaciones de firmware
CVE-2026-6687	7.6 (Alto)	Desbordamiento de búfer en la etiqueta de volumen exFAT (punto de apoyo de corrupción de memoria)
CVE-2026-6688	7.6 (Alto)	Desbordamiento por nombre de archivo largo en el código envoltorio común de FatFs
CVE-2026-6685	6.1 (Medio)	Desbordamiento de cálculo en la gestión de caché → corrupción silenciosa en volúmenes fragmentados
CVE-2026-6683	4.6 (Medio)	División por cero de exFAT; puede «ladrillar» el hardware en un flujo de actualización
CVE-2026-6686	4.6 (Medio)	Lectura más allá del final: filtra datos de archivos previamente eliminados
CVE-2026-6684	4.6 (Medio)	Tabla de particiones GPT malformada que bloquea el montaje — único corregido upstream (FatFs R0.16)

Fechas clave: 2017 — la auditoría manual de runZero apenas encuentra nada. Marzo de 2026 — el equipo reaudita con VS Code + GitHub Copilot en modo «auto», el LLM construye el fuzzer. 1 de julio de 2026 — divulgación coordinada con PoC públicos; sin respuesta del upstream pese a la implicación del JPCERT/CC. Reserva de alcance: la explotabilidad varía mucho según el dispositivo, las protecciones de memoria y cómo cada fabricante envuelve FatFs.