Critical Vulnerabilities in FluentBit Expose Cloud Environments to Remote Takeover

Executive Summary

A new chain of 5 critical vulnerabilities within Fluent Bit allows attackers to compromise cloud infrastructure. 

Fluent Bit, an open-source tool for collecting, processing, and forwarding logs is the quiet messenger of modern computing. It is embedded in billions of containers and deployed more than 15 billion times, with over 4 million pulls in the past week alone.

It runs everywhere: AI labs, banks, car manufactures, all the major cloud providers such as AWS, Google Cloud, and Microsoft Azure, and more.

When a component this widespread and trusted fails, it doesn’t just expose individual systems; it threatens the stability of the cloud ecosystem.

The Oligo Security research team findings detail the newly disclosed vulnerabilities that allow attackers to bypass authentication, perform path traversal, achieve remote code execution, cause denial-of-service conditions, and manipulate tags.

The vulnerabilities create pathways for attackers to disrupt cloud services, tamper with data, and gain deeper access to the same Cloud and  Kubernetes infrastructure. 

In practice, this means an attacker exploiting these vulnerabilities could not only disrupt cloud services and tamper with data, but also take over the logging service itself. 

The amount of control enabled by this class of vulnerabilities could allow an attacker to breach deeper into a cloud environment to execute malicious code through Fluent Bit, while dictating which events are recorded, erasing or rewriting incriminating entries to hide their tracks after an attack, injecting fake telemetry, and injecting plausible fake events to mislead responders.

Our research found that some of these vulnerabilities, such as CVE 2025-12972, have left cloud environments vulnerable for over 8 years. 

The specific vulnerabilities detailed in this report were disclosed by Oligo in collaboration with AWS through the coordinated vulnerability disclosure process. The CVEs include:

• CVE-2025-12972: Unsanitized tag values are used to generate output filenames, allowing attackers to inject path-traversal sequences like “../” to write or overwrite arbitrary files on disk, enabling log tampering and, in many configurations, full remote code execution.
• CVE-2025-12970: A stack buffer overflow in the Docker input enables attackers to trigger crashes or execute code by creating containers with excessively long names, giving them control over the Fluent Bit agent on the host.
• CVE-2025-12978: A flaw in Fluent Bit’s tag-matching logic lets attackers spoof trusted tags by guessing only the first character of a Tag_Key, enabling them to reroute logs, bypass filters, and inject malicious or misleading records.
• CVE-2025-12977: Tags derived from user-controlled fields bypass sanitization, allowing attackers to inject newlines, traversal sequences, and control characters that corrupt downstream logs or enable broader output-based attacks.
• CVE-2025-12969: Fluent Bit forwarders configured with Security.Users silently disable authentication, allowing remote attackers to send logs, inject false telemetry, or flood detection systems despite appearing secured.

This research explains the context, impact, detection guidance, and remediation steps security teams should take immediately. 

If you need assistance assessing your environment’s configurations and helping to identify potentially malicious actions related to Fluent Bit, feel free to reach out to our security team at info@oligosecurity.io.

Statement from AWS

AWS is aware of a blog post by Oligo Security, titled "Critical Vulnerabilities in Fluent Bit Expose Cloud Environments to Remote Takeover" and the related CVEs: CVE-2025-12969, CVE-2025-12970, CVE-2025-12972, CVE-2025-12977, and CVE-2025-12978. AWS has secured all of its internal systems that rely on Fluentbit through the Fluentbit project [1] and releasing Fluentbit version 4.1.1 [2].

We recommend customers that are running Fluentbit as a workload upgrade to the latest version v4.1.1 [3][4]

AWS offers customers solutions and resources to help securely manage their environments such as Amazon Inspector [5], AWS Security Hub [6], and AWS Systems Manager [7].

We would like to thank Oligo Security for disclosing this issue to the affected vendor and collaborating with AWS through the coordinated vulnerability disclosure process to keep customers secure.

[1] https://github.com/fluent/fluent-bit/ 

[2] https://github.com/fluent/fluent-bit/releases/tag/v4.1.1 

[3] https://github.com/aws/aws-for-fluent-bit 

[4]https://gallery.ecr.aws/aws-observability/aws-for-fluent-bit 

[5] https://aws.amazon.com/inspector/ 

[6] https://aws.amazon.com/security-hub/ 

[7] https://docs.aws.amazon.com/systems-manager/latest/userguide/patch-manager.html

Background: Why Fluent Bit matters

Fluent Bit is a fast, lightweight telemetry agent that ships logs, metrics, traces and is commonly deployed as a Kubernetes DaemonSet or as a host agent via packages or containers. Because it has to read from the local environment (files, sockets, systemd, containers) and send data out to remote backends, it’s often exposed both to untrusted input and to sensitive data.  Sitting directly on the ingestion path with network reachable inputs and a rich plugin ecosystem, any bug in its parsing, templating, or file-handling logic can turn into a high impact security issue.

To understand why, it helps to understand how organizations might use fluentbit. Here are some hypothetical examples:

• Banking and fintech: Collects transaction and login logs from services and forwards them to monitoring tools to identify fraud or service disruptions.
• Delivery app: Stream order and API logs from customer and driver apps into analytics pipelines to quickly spot outages or performance issues. 
• Cloud and SaaS platform: Forwards container and cloud service logs into centralized storage to simplify compliance and investigations.
• Security product: Ingests alerts from detection tools and sends them to a SIEM so analysts can see and respond to threats faster.

These are just some of the ways organizations might rely on Fluent Bit, demonstrating how vulnerabilities that impact modern infrastructure can disrupt critical services that organizations depend on.

Affected components and versions

Newly-Disclosed Vulnerabilities - Technical Details

To fully grasp the impact of the new vulnerabilities that Oligo uncovered, it’s useful to first understand the mechanisms that make Fluent Bit the widely adopted, high performance log processor it is.

At its core, it collects, transforms, and routes data. Its architecture is built around input plugins, which gather data from sources such as files, containers, HTTP endpoints, and output plugins, which deliver that data to destinations like files, cloud services, or databases. 

Each record passing through Fluent Bit carries a tag, a string used to identify and classify the data. Tags act as routing labels – that determine which filters process the record and which outputs it will be sent to. This design makes Fluent Bit highly flexible, allowing complex pipelines where logs from different sources can be enriched, transformed, and delivered to multiple outputs with fine-grained control.

‍

Below is a high-level overview of potential attack paths and capabilities an adversary could take advantage of with this chain of vulnerabilities. 

‍

Partial String Comparison of Tag_Key

CVE: CVE-2025-12978
CWE: CWE-187 (Partial String Comparison)

Affected inputs: HTTP, Splunk, Elasticsearch

Fluent Bit relies heavily on tags. Every record gets a tag, and that tag decides which filters and outputs will see it. If you route logs differently per service, per tenant, or per environment, you probably do it with tags.

When logs arrive through the HTTP input plugin, you would expect the tag to be controlled mostly by configuration. In reality, the behavior is more nuanced.

For the HTTP input, a record’s tag can come from three places, in this effective order:

1. Static Tag in the input configuration
   You can configure Tag on the HTTP input, but for HTTP traffic this value is effectively ignored. It does not control the final tag for the record.
   
   
2. The request URI
   By default, Fluent Bit derives the tag from the request path.
   Example: a POST to /api/v1/events becomes the tag api.v1.events.
   This URI based tag is used when there is no valid dynamic tag in the JSON body.
   
   
3. A JSON field configured with Tag_Key
   If you set Tag_Key in the HTTP input, Fluent Bit is supposed to look for that field in the JSON payload and use its value as the tag.
   The idea is simple: if Tag_Key custom_tag is configured and the payload contains "custom_tag": "message_tag", then the record should be tagged message_tag. This is meant to give clients dynamic control over tags.

We found that the tag_key() method does not correctly match the custom tag.

if (strncmp(ctx->tag_key, key_str, key_str_size) == 0) { ... }

tag_key() compares only key_str_size so just "c", matches configured key "custom_tag". The compare checks the size of the user input key not the actual key size, meaning that an attacker can send just the first letter and match the Tag_Key. 

Tags are used in many different ways in Fluent Bit and this vulnerability allows for attackers to control the value of Tags without knowing the Tag_Key value.

An attacker with network access to a fluentbit HTTP input server, Elasticsearch input or Splunk input, can send a json with a key from A-Z 0-9 essentially making sure one of the characters will match the key allowing them to control the tag value.

Vulnerability TL;DR

In short, by guessing just the first letter of a tag key an attacker can spoof the tag on log data and control where and how it’s processed, even without knowing the actual tag key. An attacker could hijack routing, inject fake or malicious records under trusted tags, bypass filters or monitoring, and confuse downstream systems so logs end up in unexpected databases, dashboards, or alerting tools. Any configuration that uses the HTTP, Elasticsearch and Splunk inputs with Tag_Key are vulnerable.

Improper Input Validation on Tag_Key Records

CVE: CVE-2025-12977
CWE: CWE-20

Affected inputs: HTTP, Splunk, Elasticsearch

When Fluent Bit is configured to derive tags from record fields using the tag_key option, those tags bypass the normal sanitization process applied to path-derived tags. As a result, they can contain problematic characters such as spaces, control sequences, newlines, path traversal patterns like ../, or long strings.  This becomes dangerous because many output plugins embed the tag directly into the output data or rely on the tag to generate file paths, log identifiers, or routing logic. A maliciously crafted record could therefore inject unexpected content into the final output: for example, a newline in a tag written to a log file can forge extra log entries or break parsing, and a # or // injected into an output can comment out the rest of the line or otherwise corrupt the expected format. In some configurations this can also trigger unexpected filesystem writes or enable path traversal and broader injection issues, depending on the target output. While the precise impact varies with configuration, the lack of input validation here significantly broadens the attack surface and increases the likelihood of exploitation in real world deployments.

Vulnerability TL;DR

When Fluent Bit builds tags from record fields via tag_key, they skip normal sanitization. Attackers can inject newlines, comment markers, ../, and other characters into tags that many outputs embed directly, leading to log corruption, output injection, and in some setups path traversal.

Path Traversal File Write in out_file

CVE: CVE-2025-12972

CWE: CWE-35

Vulnerable configurations: 

• Any configuration where the Tag value can be controlled (directly or indirectly) and the file output lacks a defined File key.
• HTTP input with Tag_Key set and file output missing the File key.
• Splunk input with Tag_Key set and file output missing the File key.
• Elasticsearch input with Tag_Key set and file output missing the File key.
• Forward input combined with file output missing the File key.

The File output plugin allows Fluent Bit to write logs directly to the filesystem. Each record is formatted and appended to a file, making it easy to keep a persistent copy of processed data.

The output file plugin writes output to a file specified by two configuration options

1. Path
2. File

Many common configurations use the path option. In these cases the Tag is used in order to create the file name.

There are cases where Tag is user controlled and set in the INPUT step. The file output does not filter any characters from the tag before it is written.

Attackers can use path traversal characters “../” in the Tag to change the file path and name. Since attackers can also partially control the data written to the file, this can lead to RCE on many systems.

Combining this vulnerability with CVE-2025-12977 and CVE-2025-12978 allows for easy exploitation of this vulnerability with HTTP input and File output.

Configurations with the forward input and file output are also trivially exploitable.

Vulnerability TL;DR

Fluent Bit uses tags taken straight from incoming logs to create output file names without sanitizing them, meaning an attacker can include path-traversal chars like “../”. When Fluent Bit then writes logs to disk without a fixed filename, those malicious tags can make it create or overwrite files anywhere on the filesystem, which can lead to tampered logs, planted malicious files, and remote code execution. Any configuration allows for dynamic tags from the INPUT and has a file OUTPUT without a specific File is vulnerable to path traversal.

Stack buffer overflow in in_docker

CVE:CVE-2025-12970

CWE: CWE-121

The Docker Metrics input plugin turns Docker container stats (CPU, memory, I/O, etc.) into Fluent Bit records by periodically scraping the Docker API. Because it typically runs on hosts with access to the Docker socket and container metadata, any flaw in this plugin can have a big impact in containerized environments.

The docker metrics plugin uses the extract_name function to extract running container names and stores them in a 256 byte stack buffer - buff.

‍

extract_name is present in both cgroup_v1.c and cgroup_v2.c.

As shown in the image above - the name of the container is copied to buff, a 256 byte stack buffer, without verifying that the name is shorter than 256.

An attacker who can control container names or create containers, can start a container with a long name and trigger a stack buffer overflow.

This issue can also be triggered if an attacker gains access to the Docker configuration JSON files and creates a container entry with a long name.

Vulnerability TL;DR

Fluent Bit copies a container’s name into a fixed 256-byte buffer without checking its length, so a long container name can overflow that stack buffer. An attacker who can create containers could start one with an excessively long name to crash the agent or execute arbitrary code. This issue affects setups using the Docker input.

To put this into context, an attacker could knock out logging and metrics for apps that rely on the Fluent Bit agent. In a worse scenario, the overflow could let an attacker run code  on Fluent Bit essentially giving attackers full control over the logging agent on that node. They can disable or tamper with logs and metrics, hide their own activity, read sensitive data and credentials and use that foothold to install backdoors or move laterally to other hosts and services.

Missing security.users authentication in in_forward

CVE: CVE-2025-12969

CWE: CWE-306

The in_forward plugin in Fluent Bit is a network input plugin that receives logs from other Fluent Bit or Fluentd instances using the Forward protocol. It acts as a collector or relay, listening on a TCP or TLS port (default : 24224).

Recent versions of Fluent Bit added security measures to in_forward in order to prevent unauthorized users from sending data to a forward instance.

There are multiple ways to set up authentication for the forward input. The common ones mentioned in the official documentation are using a shared key or a username and password.

We discovered that if Security.Users (username and password authentication) is specified, no authentication occurs. The current behaviour is as follows:

1. If a Shared_Key is specified - it is checked on each connection to the forwarder
2. If Shared_Key and Security.Users are specified - Both key and username+password are checked on each connection
3. If only Security.Users is specified - authentication is not enforced

The official documentation clearly states that authentication can be either shared_key or user based.

This bypass leaves many fluent-bit forwarders open to attacker connections while giving users a false sense of security. 

Vulnerability TL;DR

If a Fluent Bit forward input is configured with Security.Users but no Shared_Key, authentication is effectively disabled. That means attackers can connect to the forwarder and send logs even though operators think user-based authentication is in place. Vulnerable configurations include: a forward input that enables Security.Users but does not set a Shared_Key.

To provide an example of the impact of this vulnerability, it could allow an attacker to do something like flood a security product’s logs with false events to spam alerts to overwhelm security teams so that they don’t see an alert that is actually malicious. Beyond spamming alerts, an attacker could inject false telemetry to hide their activity, overwrite or exfiltrate logs, or feed misleading data into detection pipelines, all while operators believe user-based authentication was protecting the forwarder.

Controlling tags can also change output behavior and enable other exploits, for example, the path-traversal vulnerability.

Mitigation & remediation (concrete steps for operators)

• Update Fluent Bit to the latest stable version v4.1.1 / 4.0.12
  Ensure you’re running the most recent release, as it includes fixes for input sanitization and tag-handling logic.
  
  
• Avoid using dynamic tags for routing
  Prefer static, predefined tags in configurations to eliminate untrusted input influencing routing or file naming.
  
  
• Lock down output paths and destinations
  For outputs like file, explicitly set a fixed Path or File parameter to prevent tag-based path expansion or traversal.
  
  
• Enforce read-only configuration mounts
  Mount /fluent-bit/etc/ and configuration files as read-only to prevent runtime tampering or injection of unsafe options.
  
  
• Use least-privilege runtime settings
  Run Fluent Bit as non-root users and restrict filesystem access to only necessary directories.

Challenges in Open-Source Vulnerability Reporting

Our experience exposing these Fluent Bit issues highlights a deeper problem in today’s open-source ecosystem: the reporting and triage of security flaws often relies on volunteer maintainers with limited resources and no clear escalation path. Despite multiple responsible disclosure attempts through official channels, it took over a week, and the involvement of a major cloud provider, before the vulnerabilities received sustained attention and remediation. The process of assigning CVEs also took several weeks.

In contrast, AWS responded quickly and worked collaboratively with our team to coordinate fixes and ensure ecosystem-wide awareness through responsible coordinated disclosure. Their engagement demonstrates how proactive vendor participation can dramatically shorten remediation timelines and reduce exposure for countless downstream users.

The takeaway is clear: the security reporting and CVE assignment process for critical open-source infrastructure is still fragmented and fragile, and collaboration between maintainers, cloud providers, and security researchers is essential to keep the global software supply chain secure.

Summary

Fluent Bit sits at the heart of modern containerized environments, powering observability pipelines in Kubernetes and critical applications the world depends on every day. These vulnerabilities show how weaknesses in such a widely deployed component can ripple outward, enabling attackers to do things like hide malicious activity, tamper with data, or even compromise the very infrastructure that modern businesses rely on.

For defenders, the takeaway is clear: patching and mitigation are urgent, because in a world where Kubernetes underpins banking, retail, digital services, and more, keeping logging and telemetry secure is not just a technical necessity, but a safeguard for trust and resilience.

If you need assistance assessing your environment’s configurations and helping to identify potentially malicious actions related to Fluent Bit, feel free to reach out to our security team at info@oligosecurity.io.

‍

‍

‍

‍

‍

‍

‍

‍