Uma dependência que quase ninguém vê
A 1 de julho de 2026, a empresa de segurança runZero divulgou sete vulnerabilidades no FatFs, uma pequena biblioteca que permite a um aparelho ler e escrever os formatos FAT e exFAT usados em pens USB e cartões SD. É um daqueles pedaços de código que estão em todo o lado e visíveis para quase ninguém. Viaja no firmware de câmaras de segurança, drones, controladores industriais, carteiras cripto por hardware, quiosques públicos, caixas multibanco e máquinas de voto com porta USB.
Três das falhas têm gravidade elevada. A CVE-2026-6682 é um transbordamento de inteiros ao montar um volume FAT32; a CVE-2026-6687 transborda um buffer através da etiqueta de um volume exFAT; a CVE-2026-6688 transborda o código invólucro que muitos produtos acrescentam à volta do FatFs. Em hardware real, as piores destas tornam-se corrupção de memória e execução de código. A biblioteca chega a estes produtos através de kits de uso corrente, Espressif ESP-IDF, STMicroelectronics STM32Cube, Zephyr, MicroPython, ArduPilot, RT-Thread, Mbed, Samsung TizenRT e o atualizador SWUpdate, que é precisamente por isso que tantos fornecedores ainda não saberão que estão no raio de ação.
O acesso físico é o alvo, não a desculpa
Alguns vão desvalorizar isto dizendo que é preciso acesso físico. Para as categorias de aparelhos afetadas, isso é a vulnerabilidade, não uma mitigação. Uma câmara de segurança, um quiosque público, um multibanco, uma máquina de voto: toda a promessa de conceção é que um membro do público lhe possa tocar, ou ligar-lhe algo, sem o comprometer. Estas falhas quebram essa promessa. Um atacante com uma pen USB, um cartão SD ou um ficheiro de atualização manipulados pode corromper a memória e executar código.
Duas das falhas, o transbordamento do FAT32 e uma divisão por zero no exFAT, são também alcançáveis através de atualizações de firmware pelo ar. Isso alarga a exposição de quem está de pé diante da máquina a qualquer um que possa influenciar o canal de atualização, e significa que uma atualização falhada pode inutilizar hardware no terreno. A runZero publicou imagens de disco de prova de conceito, uma bancada de testes e um exploit funcional baseado em QEMU, pelo que o material de que um atacante precisaria já está a descoberto.
Quando a correção não tem dono
O núcleo incómodo desta história é a manutenção. O FatFs é mantido por um único programador, e a runZero diz que tentou repetidamente contactar esse responsável e envolveu o centro de coordenação JPCERT/CC do Japão, sem resposta. Apenas uma das sete falhas, um bloqueio por negação de serviço, está corrigida oficialmente na versão R0.16. Os seis problemas de corrupção de memória não têm patch oficial, nem lista de correio de segurança, nem qualquer mecanismo para que os muitos produtos que incorporam o FatFs fiquem a saber que estão afetados.
É assim que se parece, na verdade, o risco moderno da cadeia de fornecimento para ativos físicos. Não uma brecha de primeira página, mas um componente estrutural com um único ponto de falha humana, embutido tão fundo que as empresas que o distribuem não conseguem enumerar a sua própria exposição. O método de descoberta sublinha como o equilíbrio se deslocou: a runZero encontrou-as em março de 2026 com um fuzzer assistido por IA disponível sem esforço, um trabalho que uma auditoria manual anos antes tinha deixado passar. As ferramentas para encontrar estas falhas são agora baratas e de amplo acesso, o que significa que os atacantes também as têm.
O que um dono deve exigir
Não se sai disto à base de patches a partir de fora, por isso faça disto uma questão de compras e de gestão de fornecedores. Para qualquer frota de aparelhos ligados ou embebidos, câmaras, controladores, quiosques, carteiras, faça a cada fornecedor uma pergunta direta: o vosso firmware usa FatFs, que versão, e qual é o vosso plano para as seis CVE sem correção? Um fornecedor que não consiga responder depressa está a dizer-lhe algo sobre a sua própria visibilidade do seu código.
Internamente, trate as portas físicas e os canais de atualização como superfície de ataque viva. Limite quem pode ligar suportes em aparelhos expostos, e confirme que as atualizações de firmware são assinadas e validadas antes de serem aplicadas. A própria orientação da runZero às equipas de engenharia, audite a vossa versão incorporada, audite os vossos invólucros, audite o vosso tratamento de nomes e tamanhos de ficheiro, é a lista a entregar a qualquer fornecedor que construa hardware para si.
Leia a seguir: As identidades de máquina já superam os funcionários em 80 para 1 | A vitoria europeia do chip esta no silício aborrecido
