Você usa Fluent Bit no Kubernetes? 5 falhas podem permitir RCE e falsificar logs

Se você administra Kubernetes, pipelines de observabilidade ou qualquer stack moderna em nuvem, provavelmente já “convive” com o Fluent Bit sem pensar muito nele. E esse é justamente o problema: o agente que deveria levar seus logs com segurança, do ponto A ao ponto B, virou o ponto fraco do encanamento. A Oligo Security divulgou cinco falhas críticas que, em conjunto, podem permitir desde adulteração e redirecionamento de telemetria até RCE (Execução Remota de Código) e negação de serviço, com impacto potencial em ambientes presentes em AWS, Google Cloud e Microsoft Azure.

Pense no Fluent Bit como o sistema de encanamento de uma cidade (sua nuvem), levando água (dados e logs) até a estação de tratamento (seu SIEM e dashboards). As vulnerabilidades descobertas permitem que alguém não só envenene a água (injete logs falsos), como também mude o caminho dos canos (roteamento via tags), provoque rompimentos (DoS) e, no pior caso, entre na estação de tratamento para assumir o controle (RCE).

O perigo oculto no “encanamento” da nuvem

O Fluent Bit é um agente leve e escalável que coleta, processa e encaminha logs, métricas e traces. Em Kubernetes, ele costuma rodar como DaemonSet em cada nó, com acesso a volumes hostPath e a arquivos de log do sistema. Ou seja: é comum ele ficar bem perto do que é sensível, e também perto do que é “barulhento”, como inputs expostos em rede, integrações com Elasticsearch, Splunk e endpoints HTTP.

O que torna isso perigoso é o detalhe “chato” que quase ninguém debate no dia a dia: o Fluent Bit toma decisões de roteamento com base em tags. A tag é como uma etiqueta colada em cada evento, dizendo para quais filtros ele passa e para qual saída (output) ele vai. Se alguém consegue controlar a etiqueta, consegue influenciar o caminho.

A falha de 8 anos: CVE-2025-12972 e o truque do path traversal

A vulnerabilidade principal, CVE-2025-12972, é um caso clássico de path traversal, só que com um tempero que engana até profissionais experientes: o problema nasce da falta de sanitização de valores de tag que são usados para gerar nomes de arquivos em um output de arquivo (out_file). Em configurações em que a chave File não é definida, a tag vira parte do “nome do arquivo”. A partir daí, um atacante pode inserir sequências como ../ e fazer o agente escrever fora do diretório esperado.

Na prática, isso abre duas frentes graves. A primeira é a adulteração de logs, que pode apagar rastros ou fabricar evidências. A segunda é a possibilidade de sobrescrever arquivos arbitrários no disco e, dependendo de permissões e do contexto (por exemplo, montagens de volumes, execução como root, caminhos sensíveis), chegar a RCE (Execução Remota de Código). O alerta extra aqui é o tempo: a Oligo afirma que essa fragilidade ficou “escondida” no código por cerca de oito anos, o que significa uma janela silenciosa e longa para abuso em ambientes que, até ontem, se julgavam bem monitorados.

Detalhes das 5 vulnerabilidades

As outras quatro falhas não são “apenas mais CVEs”. Elas encaixam como peças para ampliar o impacto, facilitar o abuso e reduzir a chance de detecção.

• CVE-2025-12970 (Buffer overflow no Docker input): um overflow em stack associado ao input de Docker (in_docker) pode ser disparado quando containers recebem nomes grandes demais, ultrapassando um buffer fixo de 256 bytes. Com isso, dá para derrubar o agente (DoS) ou, em cenários específicos, executar código. Esse risco cresce em clusters onde um atacante consegue criar workloads, mesmo que por pouco tempo.
• CVE-2025-12978 (Tag spoofing por comparação parcial): aqui a “etiqueta” vira um crachá falsificável. Um bug na lógica de validação do Tag_Key permite que um atacante, em certos inputs (HTTP, Elasticsearch e Splunk), acerte a tag confiável “chutando” apenas o primeiro caractere. Resultado: possibilidade de redirecionar logs, burlar filtros e injetar registros que parecem legítimos.
• CVE-2025-12977 (tags derivadas de campos controlados pelo usuário sem sanitização): quando tags são formadas a partir de campos que o usuário controla, a sanitização pode ser contornada. Isso permite inserir caracteres e sequências problemáticas, como quebras de linha e até padrões que influenciam outputs, levando à corrupção de logs e a efeitos colaterais em destinos que interpretam esses dados.
• CVE-2025-12969 (desativação silenciosa de autenticação): em determinadas configurações do input forward, ao usar Security.Users sem um Shared_Key, a autenticação pode ficar “efetivamente desligada” sem avisos evidentes. É o tipo de falha que engana porque parece seguro no arquivo de configuração, mas aceita tráfego não autenticado. Na prática, permite injetar telemetria falsa, enviar logs maliciosos ou inundar sistemas de detecção para gerar fadiga operacional.

Como o ataque vira “cegueira” operacional

Imagine um atacante que já colocou o pé dentro da rede do cluster (um pod comprometido, uma credencial vazada, um endpoint interno exposto). O alvo óbvio costuma ser o app, a API, o banco. O alvo inteligente é o que conta a história do ataque: os logs.

Com as falhas de tag manipulation, o atacante pode fazer eventos “parecerem” de uma fonte confiável e passar por rotas que você trata como seguras, ou desviar eventos para caminhos onde filtros não rodam. Com o auth bypass, ele pode empurrar volumes de telemetria forjada e criar ruído, do tipo que esconde um incidente real na multidão de alertas. E com o path traversal, dá para transformar o Fluent Bit em uma ferramenta de escrita arbitrária no host, abrindo caminho para comprometer o próprio pipeline de observabilidade.

A ironia cruel é esta: você pode ter o melhor SIEM do mundo, mas se o encanamento estiver envenenado, o painel vira uma visão bonita de dados errados.

O que fazer agora: atualização imediata e ajustes rápidos

A recomendação principal é direta: atualize para 4.1.1 ou 4.0.12 o quanto antes. A AWS já tratou o caso como prioridade e migrou seus componentes para uma versão corrigida, um sinal claro do nível de urgência. Além do patch, alguns cuidados reduzem muito o raio de explosão:

• Evite tags dinâmicas derivadas de input não confiável para roteamento.
• Em outputs de arquivo, defina explicitamente Path e File (não deixe o nome depender de tag).
• Restrinja ao máximo os inputs expostos em rede, e trate forward/HTTP como superfície de ataque, não como “tráfego interno inocente”.
• Rode o agente com menor privilégio possível, use mounts de configuração read-only e limite acesso a filesystem.