Falhas sem correção no FatFs afetam milhões de dispositivos embarcados

A empresa de segurança runZero revelou sete vulnerabilidades no FatFs, uma pequena biblioteca de sistema de arquivos usada para permitir que dispositivos leiam e gravem nos formatos FAT e exFAT, comuns em pendrives USB, cartões SD e mídias de armazenamento removíveis.

O problema chama atenção pela ampla presença do FatFs em dispositivos embarcados. A biblioteca é incorporada ao firmware de câmeras de segurança, drones, controladores industriais, carteiras físicas de criptomoedas, equipamentos baseados em sistemas operacionais de tempo real e diversos outros produtos conectados ou especializados.

Nos sistemas mais afetados, um invasor que consiga inserir em um dispositivo um pendrive, cartão SD ou arquivo de atualização manipulado pode provocar corrupção de memória e, em determinados cenários, executar código próprio no equipamento. Esse tipo de falha é especialmente preocupante em ambientes embarcados porque muitos desses dispositivos não contam com as mesmas proteções de memória presentes em smartphones, notebooks e desktops modernos.

Segundo a runZero, em alguns casos “qualquer acesso físico leva a um jailbreak”. A frase resume o risco de um cenário em que um simples contato com uma porta USB, um slot para cartão SD ou um fluxo de atualização pode ser suficiente para assumir controle indevido de um dispositivo. Em tese, quiosques públicos, câmeras com entrada SD, caixas eletrônicos ou máquinas de votação com porta USB não deveriam permitir comprometimento total após poucos instantes de acesso físico, mas as vulnerabilidades mostram que esse risco pode existir.

As sete falhas seguem a mesma lógica geral. O dispositivo tenta ler um volume de armazenamento ou uma imagem de firmware deliberadamente malformada, e o FatFs processa esses dados incorretamente. A runZero classificou o conjunto com pontuações CVSS de severidade média a alta, sem vulnerabilidades críticas.

A principal falha é a CVE-2026-6682, com CVSS 7.6 e severidade alta. Trata-se de um integer overflow no código responsável por montar volumes FAT32. Na prática, um erro de cálculo pode gerar um tamanho de arquivo falso, que depois é interpretado por outras partes do código como um tamanho real de leitura. Em hardware real, esse comportamento pode levar à corrupção de memória e possível execução de código.

Outra vulnerabilidade de alto impacto é a CVE-2026-6687, também com CVSS 7.6. Ela envolve um campo de rótulo de volume exFAT que pode estourar um buffer pequeno, oferecendo ao invasor um ponto de entrada para corrupção de memória. A CVE-2026-6688, com a mesma pontuação, afeta nomes longos de arquivos e pode explorar falhas no código de integração que muitos projetos adicionam ao redor do FatFs, como o uso de strcpy para copiar fno.fname para buffers fixos. Por esse motivo, a correção não depende apenas do FatFs, mas também de como cada fornecedor implementou a biblioteca.

Entre as falhas de severidade média está a CVE-2026-6685, com CVSS 6.1, causada por um erro matemático no tratamento de cache em volumes fragmentados. O problema pode provocar corrupção silenciosa de dados. A CVE-2026-6683, com CVSS 4.6, é uma divisão por zero em exFAT que pode travar o dispositivo e, em fluxos de atualização, até inutilizar o hardware. Essa falha também pode ser explorada por meio de alguns processos de firmware update.

A CVE-2026-6686, com CVSS 4.6, permite que um arquivo estendido além de seu fim vaze dados residuais de arquivos apagados anteriormente. Já a CVE-2026-6684, também com CVSS 4.6, envolve uma tabela de partição GPT malformada, capaz de fazer o dispositivo travar durante o processo de montagem. Essa é a única das sete vulnerabilidades que já foi corrigida no projeto original, na versão FatFs R0.16.

A parte mais difícil do caso está na cadeia de correção. O FatFs é mantido por um único desenvolvedor em uma estrutura pequena e pouco formalizada. Segundo a runZero, a empresa tentou contato repetidas vezes com o mantenedor e envolveu o JPCERT/CC, centro japonês de coordenação de vulnerabilidades, mas não obteve resposta.

De acordo com a runZero, não há correção upstream para as falhas de corrupção de memória, não existe uma lista pública de segurança e não há um processo claro para que os inúmeros produtos que integram o FatFs sejam informados de que estão vulneráveis. Atualizar para a versão mais recente ajuda no caso da falha de travamento envolvendo GPT, mas as demais correções ficam nas mãos dos fornecedores que incorporaram a biblioteca a seus próprios produtos.

A empresa citou plataformas afetadas como Espressif ESP-IDF, STMicroelectronics STM32Cube, Zephyr, MicroPython, ArduPilot, RT-Thread, Mbed, Samsung TizenRT e SWUpdate. Isso amplia o alcance do problema para dispositivos IoT de consumo, equipamentos industriais, drones, carteiras físicas de criptomoedas e mecanismos de atualização de firmware.

Até a divulgação da runZero em 1º de julho, não havia relatos de ataques explorando essas vulnerabilidades, e nenhum caso público foi identificado desde então. Ainda assim, o material de exploração já está disponível. A empresa publicou imagens de disco para prova de conceito, um ambiente de testes e um exemplo funcional de exploração baseado em QEMU em um repositório complementar.

Para fabricantes que desenvolvem firmware capaz de interagir com mídias FAT ou exFAT, a recomendação é localizar a cópia do FatFs usada no produto, auditar o código de integração ao redor da biblioteca, revisar com atenção o tratamento de nomes de arquivos e tamanhos de arquivos e planejar correções. Em muitos casos, o risco não estará apenas na biblioteca original, mas na forma como cada projeto usa seus retornos, buffers e estruturas.

Para organizações que operam dispositivos potencialmente afetados, portas físicas e canais de atualização devem ser tratados como superfície de ataque. Isso significa limitar quem pode conectar mídias removíveis, controlar o acesso físico a equipamentos expostos, validar processos de atualização de firmware e acompanhar comunicados dos fornecedores.

O caso também mostra uma tendência mais ampla na descoberta de vulnerabilidades em bibliotecas C amplamente embarcadas. A runZero havia auditado manualmente o FatFs em 2017 e encontrou pouco material relevante para reporte. Em março de 2026, a equipe retornou ao mesmo código usando uma configuração relativamente comum: Visual Studio Code, GitHub Copilot em modo automático e alguns prompts simples.

Com esse apoio, o modelo de linguagem gerou um fuzzer, ferramenta usada para fornecer dados malformados ao código até que algo falhe. Esse processo revelou bugs que a auditoria manual anterior não havia identificado e ajudou a confirmar que eles eram exploráveis.

A descoberta se encaixa em um padrão recente. No fim de 2024, o agente Big Sleep, do Google, encontrou uma falha real e explorável de memória no SQLite que havia passado despercebida por fuzzing convencional. Mais recentemente, um agente autônomo de IA revelou 21 bugs de segurança de memória no FFmpeg, outra biblioteca em C amplamente embarcada em produtos e projetos.

O argumento da runZero é direto: se uma abordagem relativamente acessível com IA consegue encontrar esse tipo de falha, agentes maliciosos também podem fazer o mesmo. Por isso, manter vulnerabilidades em silêncio não protege os usuários, especialmente quando o código está presente em milhões de dispositivos e a cadeia de correção é lenta ou fragmentada.

O desafio de patching tende a ser prolongado. A runZero avalia que as correções downstream podem levar anos, não dias. O precedente citado é o PixieFail, conjunto de nove vulnerabilidades divulgado em 2024 no código de boot de rede do EDK II, firmware usado por diversas marcas de PCs e servidores, cuja correção demorou a chegar a muitos fornecedores.

O caso do FatFs tem formato semelhante, mas com um agravante: a ausência de um upstream responsivo para coordenar correções. Até que o mantenedor publique patches ou que grandes plataformas que incorporam a biblioteca adotem mitigação própria, muitos dispositivos em operação provavelmente continuarão lendo mídias não confiáveis com código vulnerável e sem uma correção central disponível.