1 июля компания runZero опубликовала результаты аудита библиотеки FatFs — небольшого куска кода, который позволяет встраиваемым устройствам работать с файловыми системами FAT и exFAT на USB-накопителях и SD-картах. Найдено семь уязвимостей. Шесть из них по-прежнему не исправлены на уровне самой библиотеки. Патчей не будет ещё долго — по оценке runZero, счёт идёт на годы.
FatFs — это проект одного человека, который тихо живёт где-то на задворках интернета. Несмотря на это, библиотека встроена в прошивки десятков платформ и работает на миллионах устройств: промышленных контроллерах, охранных камерах, дронах, аппаратных криптовалютных кошельках и многом другом. Espressif ESP-IDF, STMicroelectronics STM32Cube, Zephyr, MicroPython, ArduPilot, RT-Thread, Mbed, Samsung TizenRT, SWUpdate — всё это использует FatFs. runZero пытались связаться с мейнтейнером через японский JPCERT/CC. Ответа не последовало.
Механика всех семи уязвимостей одинакова: устройство пробует прочитать специально испорченный носитель или образ прошивки, FatFs неправильно обрабатывает кривые данные, и дальше — в зависимости от конкретного бага — либо память летит, либо устройство падает в краш, либо что-то ещё. Физический носитель или канал обновления прошивки становятся вектором атаки. Многие встраиваемые системы не имеют защит памяти, которые есть на смартфонах и компьютерах, поэтому runZero пишут прямо: на уязвимых устройствах любой физический доступ превращается в джейлбрейк. Публичные киоски, банкоматы, камеры со слотом для SD, машины для голосования с USB — всё это потенциальные цели.
Самые серьёзные три уязвимости получили CVSS 7.6. CVE-2026-6682 — переполнение целого числа в коде монтирования FAT32-тома. Кривая математика производит ложный размер файла, а последующий код воспринимает его как реальную длину чтения. Итог — повреждение памяти и возможное выполнение произвольного кода. CVE-2026-6687 — переполнение буфера в поле метки тома exFAT: поле вытекает за границу маленького буфера, и у атакующего появляется контроль над памятью. CVE-2026-6688 — переполнение буфера при обработке длинных имён файлов в обёрточном коде вокруг FatFs, например через
Четыре оставшихся бага — средней тяжести. CVE-2026-6685 (CVSS 6.1) — математическое переполнение в логике кэша на фрагментированных томах, приводит к тихому повреждению данных. CVE-2026-6683 (CVSS 4.6) — деление на ноль в обработке exFAT, роняет устройство, а если это происходит во время обновления прошивки — может превратить железку в кирпич. CVE-2026-6686 (CVSS 4.6) — утечка данных через расширение файла за его пределы, позволяет читать остаточные данные от ранее удалённых файлов. CVE-2026-6684 (CVSS 4.6) — зависание при разборе повреждённой таблицы разделов GPT во время монтирования. Это единственный баг, который получил исправление в апстриме — в версии FatFs R0.16.
runZero не стали придерживать материалы. Вместе с раскрытием они опубликовали proof-of-concept — образы дисков, тестовый стенд и рабочий пример эксплойта на базе QEMU. Логика простая: если стандартный AI-конвейер на готовых инструментах может найти эти баги, то злоумышленник тоже может. Тихое замалчивание ничего не защищает.
Что касается самого процесса обнаружения — история двухэтапная. В 2017 году runZero уже проводили ручной аудит FatFs и нашли мало чего интересного. В марте 2026 года они вернулись, но уже с другим инструментарием: Visual Studio Code, GitHub Copilot в режиме "auto" и несколько простых промптов. Языковая модель сама построила фаззер — инструмент, который скармливает коду искажённые данные до тех пор, пока что-нибудь не сломается. Фаззер нашёл баги, которые ручной аудит пропустил, и помог подтвердить эксплуатируемость.
Это не единственный такой случай. В конце 2024 года агент Google Big Sleep нашёл реальный эксплуатируемый баг в SQLite, который пропустил обычный фаззинг. За месяц до раскрытия runZero автономный AI-агент обнаружил 21 уязвимость в области безопасности памяти в FFmpeg — ещё одной библиотеке на Си, которая встроена повсюду. Порог входа для поиска таких дыр снизился. Это меняет саму логику ответственного раскрытия.
Ближайшая историческая аналогия — PixieFail в 2024 году. Тогда нашли девять уязвимостей в сетевом загрузочном коде EDK II, прошивки, которая стоит во многих ПК и серверах. Вендоры латали медленно. Но там хотя бы был живой апстрим. С FatFs ситуация хуже: апстрим молчит, а ответственность за исправления полностью лежит на вендорах, которые встроили библиотеку в свои продукты.
Что конкретно делать тем, кто разрабатывает прошивки: найти копию FatFs в своём продукте, проаудировать обёрточный код вокруг неё, особое внимание уделить обработке имён файлов и размеров файлов. Ждать апстрима не стоит. Тем, кто эксплуатирует устройства: физические порты и каналы обновления — это поверхность атаки. Надо ограничить круг тех, кто может подключать носители, и следить за обновлениями прошивок от вендоров. Пока многие устройства, которые уже стоят на полках и в стойках, читают недоверенные носители с уязвимым кодом без каких-либо исправлений.
FatFs — это проект одного человека, который тихо живёт где-то на задворках интернета. Несмотря на это, библиотека встроена в прошивки десятков платформ и работает на миллионах устройств: промышленных контроллерах, охранных камерах, дронах, аппаратных криптовалютных кошельках и многом другом. Espressif ESP-IDF, STMicroelectronics STM32Cube, Zephyr, MicroPython, ArduPilot, RT-Thread, Mbed, Samsung TizenRT, SWUpdate — всё это использует FatFs. runZero пытались связаться с мейнтейнером через японский JPCERT/CC. Ответа не последовало.
Механика всех семи уязвимостей одинакова: устройство пробует прочитать специально испорченный носитель или образ прошивки, FatFs неправильно обрабатывает кривые данные, и дальше — в зависимости от конкретного бага — либо память летит, либо устройство падает в краш, либо что-то ещё. Физический носитель или канал обновления прошивки становятся вектором атаки. Многие встраиваемые системы не имеют защит памяти, которые есть на смартфонах и компьютерах, поэтому runZero пишут прямо: на уязвимых устройствах любой физический доступ превращается в джейлбрейк. Публичные киоски, банкоматы, камеры со слотом для SD, машины для голосования с USB — всё это потенциальные цели.
Самые серьёзные три уязвимости получили CVSS 7.6. CVE-2026-6682 — переполнение целого числа в коде монтирования FAT32-тома. Кривая математика производит ложный размер файла, а последующий код воспринимает его как реальную длину чтения. Итог — повреждение памяти и возможное выполнение произвольного кода. CVE-2026-6687 — переполнение буфера в поле метки тома exFAT: поле вытекает за границу маленького буфера, и у атакующего появляется контроль над памятью. CVE-2026-6688 — переполнение буфера при обработке длинных имён файлов в обёрточном коде вокруг FatFs, например через
strcpy содержимого fno.fname в буфер фиксированного размера. Эту проблему сложно починить внутри самой библиотеки — она касается обёрток, которые используют многие проекты. Четыре оставшихся бага — средней тяжести. CVE-2026-6685 (CVSS 6.1) — математическое переполнение в логике кэша на фрагментированных томах, приводит к тихому повреждению данных. CVE-2026-6683 (CVSS 4.6) — деление на ноль в обработке exFAT, роняет устройство, а если это происходит во время обновления прошивки — может превратить железку в кирпич. CVE-2026-6686 (CVSS 4.6) — утечка данных через расширение файла за его пределы, позволяет читать остаточные данные от ранее удалённых файлов. CVE-2026-6684 (CVSS 4.6) — зависание при разборе повреждённой таблицы разделов GPT во время монтирования. Это единственный баг, который получил исправление в апстриме — в версии FatFs R0.16.
runZero не стали придерживать материалы. Вместе с раскрытием они опубликовали proof-of-concept — образы дисков, тестовый стенд и рабочий пример эксплойта на базе QEMU. Логика простая: если стандартный AI-конвейер на готовых инструментах может найти эти баги, то злоумышленник тоже может. Тихое замалчивание ничего не защищает.
Что касается самого процесса обнаружения — история двухэтапная. В 2017 году runZero уже проводили ручной аудит FatFs и нашли мало чего интересного. В марте 2026 года они вернулись, но уже с другим инструментарием: Visual Studio Code, GitHub Copilot в режиме "auto" и несколько простых промптов. Языковая модель сама построила фаззер — инструмент, который скармливает коду искажённые данные до тех пор, пока что-нибудь не сломается. Фаззер нашёл баги, которые ручной аудит пропустил, и помог подтвердить эксплуатируемость.
Это не единственный такой случай. В конце 2024 года агент Google Big Sleep нашёл реальный эксплуатируемый баг в SQLite, который пропустил обычный фаззинг. За месяц до раскрытия runZero автономный AI-агент обнаружил 21 уязвимость в области безопасности памяти в FFmpeg — ещё одной библиотеке на Си, которая встроена повсюду. Порог входа для поиска таких дыр снизился. Это меняет саму логику ответственного раскрытия.
Ближайшая историческая аналогия — PixieFail в 2024 году. Тогда нашли девять уязвимостей в сетевом загрузочном коде EDK II, прошивки, которая стоит во многих ПК и серверах. Вендоры латали медленно. Но там хотя бы был живой апстрим. С FatFs ситуация хуже: апстрим молчит, а ответственность за исправления полностью лежит на вендорах, которые встроили библиотеку в свои продукты.
Что конкретно делать тем, кто разрабатывает прошивки: найти копию FatFs в своём продукте, проаудировать обёрточный код вокруг неё, особое внимание уделить обработке имён файлов и размеров файлов. Ждать апстрима не стоит. Тем, кто эксплуатирует устройства: физические порты и каналы обновления — это поверхность атаки. Надо ограничить круг тех, кто может подключать носители, и следить за обновлениями прошивок от вендоров. Пока многие устройства, которые уже стоят на полках и в стойках, читают недоверенные носители с уязвимым кодом без каких-либо исправлений.
