Уязвимости във FatFs показват скрития риск във firmware компонентите на вградените устройства

Обзор

Изследователи от runZero разкриха седем уязвимости във FatFs — лек FAT/exFAT filesystem компонент, използван в много embedded, IoT и firmware среди. Уязвимостите са проследени като CVE-2026-6682 до CVE-2026-6688 и засягат начина, по който FatFs обработва FAT32, exFAT и GPT структури.

Нито една от уязвимостите не е оценена като Critical, но обхватът е значим. FatFs се използва в голям брой downstream проекти, SDK среди, микроконтролери, RTOS платформи и устройства, които разчитат на SD карти, USB носители, firmware update процеси или локално съхранение.

Темата е важна, защото показва как малък, дълго използван компонент може да създаде риск в милиони устройства, без организацията винаги да знае, че този компонент присъства в нейната среда.

Какво се случва

runZero публикува анализ на седем уязвимости във FatFs, свързани с memory corruption, отказ на услуга, изтичане на данни, silent data corruption и проблеми при обработка на файлови структури.

Най-сериозните уязвимости включват:

• CVE-2026-6682 — integer overflow при FAT32 mount логика, който може да доведе до неправилни file-size стойности, unsafe reads и потенциална memory corruption;
• CVE-2026-6687 — stack overflow в exFAT volume label обработка, когато дължината на label полето не се ограничава правилно;
• CVE-2026-6688 — риск от buffer overflow при downstream wrapper код, когато long filename стойности се копират в фиксирани буфери без достатъчна проверка.

Останалите уязвимости включват divide-by-zero, uninitialized data exposure, mount-time denial-of-service и stale cache поведение при определени сценарии.

Защо това има значение

FatFs не е приложение, което потребителят вижда. То е библиотека, която често е вградена дълбоко във firmware, SDK или RTOS среда. Именно това прави риска по-труден за управление.

Организациите може да използват устройства, които съдържат FatFs, без това да е очевидно от asset inventory или стандартен vulnerability scan. Това важи особено за:

• индустриални контролери;
• IoT устройства;
• медицински устройства;
• камери и сензори;
• дронове;
• embedded Linux и RTOS системи;
• крипто хардуер;
• устройства с USB или SD card интерфейси;
• firmware update механизми.

Когато уязвимостта е във firmware dependency, patching процесът става по-сложен. Не е достатъчно да се приложи update на операционна система. Нужно е downstream доставчикът да включи корекцията, да я валидира за конкретния хардуер и да предостави firmware update.

Как могат да се задействат уязвимостите

Публичният анализ посочва, че проблемите могат да се задействат чрез специално подготвени FAT, exFAT или GPT изображения. В зависимост от устройството това може да стане чрез:

• SD карта;
• USB носител;
• removable media;
• firmware update image;
• OTA update процес;
• auto-mounted storage;
• service процедура или maintenance workflow.

Това не означава, че всяко устройство може да бъде атакувано дистанционно. При много сценарии е нужен физически достъп или достъп до update процес. Но в embedded средите физическият достъп не винаги е висок праг. Устройства в публични пространства, производствени зони, магазини, терминали, лаборатории или remote sites често имат достъпни портове или сменяеми носители.

Потенциален ефект

Ефектът зависи от конкретната интеграция на FatFs, активираните функции и защитите на устройството.

Възможните последствия включват:

• отказ на услуга при mount или write/sync операции;
• memory corruption;
• потенциално изпълнение на код при определени условия;
• изтичане на остатъчни данни от предишно съдържание;
• silent data corruption;
• проблеми при firmware update процеси;
• компрометиране на устройство чрез crafted media;
• труден patch процес за устройства с дълъг жизнен цикъл.

Рискът е по-висок при устройства без силна memory protection, без ASLR, без процесна изолация или с автоматично монтиране на външни носители.

Защо embedded рискът е различен

При сървъри и работни станции vulnerability management обикновено следва ясен процес: откриване, patch, рестарт, проверка. При embedded устройства процесът рядко е толкова директен.

Причините са няколко:

• компонентът може да е vendored и модифициран;
• доставчикът може да не публикува бързо firmware update;
• устройството може да е в експлоатация години след края на активна поддръжка;
• update процесът може да изисква физически достъп;
• прекъсването на устройството може да има operational impact;
• стандартните скенери може да не виждат embedded dependencies.

Това прави FatFs уязвимостите по-скоро supply chain и asset visibility проблем, отколкото само technical patching задача.

Препоръчителни действия

Организациите, които използват embedded, IoT или OT устройства, трябва да проверят дали FatFs присъства в техните продукти, firmware, SDK или доставени устройства.

Приоритетни действия:

• изискайте информация от доставчици дали техните устройства използват FatFs;
• проверете firmware SBOM, ако е наличен;
• идентифицирайте устройства с USB, SD card или removable media интерфейси;
• ограничете auto-mount поведение, когато не е необходимо;
• ограничете физическия достъп до портове на устройства в публични или semi-public среди;
• проверете firmware update процесите и дали приемат FAT/exFAT/GPT images;
• валидирайте update images преди инсталация;
• следете за vendor advisories и downstream patches;
• прегледайте wrapper код, който обработва long filenames, volume labels и file-size стойности;
• включете embedded dependencies в vulnerability management процеса.

При критични среди трябва да се направи приоритизация според exposure. Устройство с публично достъпен USB порт, OTA update канал или критична функция има различен риск от изолирано устройство без външен storage interface.

DIAMATIX перспектива

Този случай показва защо видимостта върху активите трябва да стига по-дълбоко от операционни системи, сървъри и приложения. В много среди реалният риск се намира във firmware, библиотеки, SDK и компоненти, които рядко се появяват в стандартните security dashboards.

FatFs е добър пример за малък компонент с голям operational footprint. Той не е самостоятелен продукт, но присъства в продукти, които организациите използват всеки ден. Това усложнява въпроса „засегнати ли сме?“, защото отговорът често зависи от доставчици, firmware версии и локални модификации.

Защитата изисква:

• по-добър asset inventory;
• въпроси към доставчиците за embedded dependencies;
• контрол върху removable media;
• процес за firmware patching;
• наблюдение на OT/IoT устройствата;
• risk-based приоритизация, а не само CVSS оценка.

Основният урок е ясен: supply chain рискът не свършва при софтуерните пакети в облака. Той присъства и в малките компоненти, които управляват файлове, storage, update процеси и device behavior.

CISO анализ

От гледна точка на CISO FatFs уязвимостите поставят няколко практически въпроса:

• Знаем ли кои embedded устройства използваме и кой ги поддържа?
• Имаме ли SBOM или друг начин да разберем дали FatFs присъства във firmware?
• Кои устройства позволяват USB, SD card или друг removable media достъп?
• Има ли устройства, които автоматично монтират външни носители?
• Как се валидират firmware updates и OTA packages?
• Кои устройства са критични за производство, здравни процеси, физическа сигурност или инфраструктура?
• Какъв е планът, ако доставчикът няма готов patch?
• Може ли SOC екипът да види необичайно поведение от embedded или IoT устройства?

Този тип риск не се решава само с patch. Той изисква връзка между procurement, IT, OT, security, vendors и operations.

Какво означава това за вашата среда

• Този тип риск разчита на широко използвани embedded компоненти, които често остават скрити в firmware, SDK и device supply chain.
• Откриването зависи от видимост върху embedded устройства, removable media, firmware версии, vendor dependencies и update процеси.
• Реакцията изисква проверка с доставчици, ограничаване на физически и update канали, firmware patch planning и приоритизация според business impact.

Знаете ли кои от вашите устройства използват FatFs или сходни embedded filesystem компоненти?

Можете ли да приоритизирате firmware риска според това кои устройства поддържат критични процеси?

Виж как подобни рискове във firmware и embedded среди се анализират и управляват в реална оперативна среда.

Клиентски казус: DIAMATIX и Acronis помагат на производствени организации да изградят по-висока оперативна устойчивост с Backup и Disaster Recovery

Свържете се с DIAMATIX
Trusted · Innovative · Vigilant

Източници

• runZero. Seven FatFs bugs, one very large blast radius.
• runZero advisories for CVE-2026-6682, CVE-2026-6683, CVE-2026-6684, CVE-2026-6686, CVE-2026-6687 and CVE-2026-6688.
• NVD records for FatFs CVE-2026-6682, CVE-2026-6683 and CVE-2026-6687.
• ChaN FatFs official project documentation.
• The Hacker News. Unpatched flaws disclosed in filesystem bundled into millions of embedded devices.

Статията е базирана на публично достъпна техническа информация и анализи към юли 2026 г.