The Fluentd project published four security advisories on June 26, 2026, the most critical of which — CVE-2026-44024 (GHSA-44hj-4m45-frj3) — carries a CVSS score of 10.0 and enables unauthenticated remote code execution via arbitrary file write. The vulnerability exists in how Fluentd handles the ${tag} placeholder in dynamic file path configurations: an attacker who controls log event tags can use path traversal sequences in the tag value to write files to arbitrary locations on the server, including cron directories, authorized_keys files, or application directories — leading to code execution.

Three additional vulnerabilities were disclosed alongside the RCE: a credential exposure issue via the Monitor Agent API (GHSA-pr7j-96cj-549h), a denial-of-service via gzip decompression bomb (GHSA-j9cw-hwqf-85w7), and a Server-Side Request Forgery via the out_http plugin (GHSA-72f5-rr8c-r6gr). All four are fixed in Fluentd 1.19.3.

Fluentd is one of the most widely deployed log aggregation platforms in cloud-native and Kubernetes environments, handling log collection for millions of services. Any Fluentd deployment using out_file or similar plugins with ${tag} in the path configuration is vulnerable to the CVSS 10.0 RCE.

What the Vulnerabilities Are

CVE-2026-44024 / GHSA-44hj-4m45-frj3 (CVSS 10.0) — RCE via Arbitrary File Write in ${tag} Placeholder

Fluentd allows the use of placeholder variables in output plugin configurations. The ${tag} placeholder inserts the log event's tag value into a file path. A common configuration pattern looks like:

<match **>
  @type file
  path /var/log/fluentd/${tag}
</match>

In this pattern, if an attacker can control the tag value of log events (by sending crafted log data to Fluentd's input plugins, by manipulating the source system generating events, or through any mechanism that allows tag injection), they can include path traversal sequences in the tag:

tag: "../../etc/cron.d/backdoor"

Fluentd writes the log output to the resolved path — /etc/cron.d/backdoor — with attacker-controlled content. Writing to /etc/cron.d/ creates a cron job that executes as root. Writing to ~/.ssh/authorized_keys injects an attacker SSH key. Writing to application directories plants a persistent backdoor.

The vulnerability requires no authentication to Fluentd itself — it only requires the ability to cause Fluentd to receive a log event with a maliciously crafted tag. This is trivially achievable in any Fluentd deployment that collects logs from attacker-influenced sources: container logs, application logs from internet-facing services, syslog from network devices, etc.

Affected versions: Fluentd ≤ 1.19.2
Fixed version: 1.19.3

Published June 26, 2026 by Watson1978 (Fluentd core maintainer).

CVE-2026-44025 / GHSA-pr7j-96cj-549h (High) — Credential Exposure via Monitor Agent API

Fluentd's Monitor Agent plugin (in_monitor_agent) provides a REST API on port 24220 for operational monitoring. This API returns detailed configuration information about the running Fluentd instance. CVE-2026-44025 discloses that this API leaks sensitive credential information without authentication — including API keys, database connection strings, cloud provider tokens, and other secrets embedded in Fluentd plugin configurations.

Any Fluentd deployment running in_monitor_agent (which is enabled by default in many distributions and Helm charts) and where port 24220 is reachable from untrusted networks is vulnerable to credential harvesting without any authentication.

Affected versions: Fluentd ≤ 1.19.2
Fixed version: 1.19.3

CVE-2026-44160 / GHSA-j9cw-hwqf-85w7 (High) — DoS via Gzip Decompression Bomb

The in_http and in_forward plugins in Fluentd accept gzip-compressed payloads. CVE-2026-44160 allows an attacker to send a gzip decompression bomb — a small compressed payload that expands to extremely large size in memory — causing Fluentd to exhaust available memory and crash or become unresponsive. No authentication is required; any system that can send HTTP or TCP input to Fluentd's input plugins can trigger the DoS.

Affected versions: Fluentd ≤ 1.19.2
Fixed version: 1.19.3

CVE-2026-44161 / GHSA-72f5-rr8c-r6gr (High) — SSRF via Placeholder Expansion in out_http

The out_http plugin supports placeholder variables in the destination URL configuration. If attacker-controlled data reaches a placeholder that is interpolated into the URL, the attacker can redirect Fluentd's HTTP output to internal network destinations — enabling Server-Side Request Forgery. This can be used to reach internal services (metadata APIs, internal databases, other microservices) that are not accessible from the external network but are reachable from the Fluentd host.

Affected versions: Fluentd ≤ 1.19.2
Fixed version: 1.19.3

Why It Matters

Fluentd is the log backbone of cloud-native infrastructure. Fluentd and Fluent Bit are the de facto standard log aggregation layers in Kubernetes, AWS, GCP, and Azure environments. They sit at the intersection of every service's log output and centralized log storage. An attacker who can influence what Fluentd writes — or where it writes — can affect every system Fluentd touches.

The RCE primitive is the worst kind: write-what-where. CVE-2026-44024 is an arbitrary file write with attacker-controlled content and attacker-controlled destination path. This is not a memory corruption exploit requiring a heap layout to be perfect — it is a deterministic write to any file the Fluentd process has permission to create or overwrite. In environments where Fluentd runs as root (common in Kubernetes DaemonSet deployments for privileged log access), this is a direct path to full host compromise.

Log sources are often attacker-influenced. The attack surface for CVE-2026-44024 is any log event where the tag can be influenced. In containerized environments, containers generate their own log tags. An attacker who has compromised one container can craft log events with malicious tags, causing Fluentd (potentially running at a higher privilege level as a DaemonSet) to write attacker-controlled files to the host. This is a container escape primitive.

The Monitor Agent credential leak targets secrets at the log layer. Fluentd integrations typically hold credentials to every downstream destination: Elasticsearch API keys, S3 access keys, Splunk HEC tokens, Datadog API keys, database connection strings. CVE-2026-44025 exposes all of these to any attacker who can reach port 24220 — often left open in internal networks where "trusted" perimeters are assumed.

All four CVEs are fixed in the same upgrade. Fluentd 1.19.3 addresses CVE-2026-44024 through -44161. A single upgrade resolves all four issues, making the cost of remediation low relative to the severity.

Am I Affected?

You are affected if you run Fluentd version 1.19.2 or earlier in any configuration.

To check your Fluentd version:

fluentd --version
# or, if running as a gem:
gem list | grep fluentd
# or in a container/pod:
kubectl exec -n <fluentd-namespace> <fluentd-pod> -- fluentd --version

For CVE-2026-44024 specifically, your vulnerability is highest if your configuration uses ${tag} in file output paths. Search your Fluentd configuration:

grep -r '\${tag}' /etc/fluent/ /etc/fluentd/ /fluentd/etc/
# or in Kubernetes ConfigMaps:
kubectl get configmap -n <namespace> -o yaml | grep '\${tag}'

Any match in a path, symlink_path, or similar directive of an out_file (or out_s3, out_gcs, or other file-writing) plugin indicates the vulnerable pattern.

For CVE-2026-44025, check whether in_monitor_agent is configured:

grep -r 'monitor_agent' /etc/fluent/ /etc/fluentd/ /fluentd/etc/

If found, also verify whether port 24220 is accessible from untrusted networks.

What to Do About It: Step-by-Step

Step 1: Upgrade to Fluentd 1.19.3.

# Via gem (standard installation):
gem update fluentd

# Via td-agent (Treasure Data's packaged distribution):
# Check your platform's package manager for td-agent 4.x updates

# Via Docker/Kubernetes:
# Pull the updated fluent/fluentd:v1.19.3 image
# Update your DaemonSet/Deployment image reference:
kubectl set image daemonset/fluentd fluentd=fluent/fluentd:v1.19.3 -n <namespace>

Restart Fluentd after upgrading to load the patched version.

Step 2: Immediately sanitize ${tag} usage in file path configurations (defense-in-depth even after patching).

Even after patching, consider replacing ${tag} in file path configurations with explicitly allowlisted tag segments, or replacing it with ${tag_parts[0]} / ${tag_parts[1]} (specific tag components) which are safer patterns. Alternatively, configure an input filter to strip path traversal sequences from tags before they reach file output plugins.

Step 3: Restrict or disable the Monitor Agent API if not required.

If in_monitor_agent is running and credential exposure is a concern, either:

  • Remove or comment out the in_monitor_agent block from your Fluentd configuration and restart
  • Or restrict access to port 24220 at the network/firewall level to only monitoring hosts

If you keep the Monitor Agent running for operational purposes, audit what credentials appear in its output:

curl -s http://localhost:24220/api/plugins.json | python3 -m json.tool | grep -i "api_key\|password\|secret\|token\|credential"

Rotate any credentials exposed in this output.

Step 4: Validate file output plugin configurations for unintended files.

If your Fluentd deployment used ${tag} in paths and was accessible to attacker-influenced log sources, audit recently written files in directories accessible to the Fluentd process user:

# Check for recently created/modified files in sensitive directories:
find /etc/cron.d /etc/cron.daily /etc/cron.hourly ~/.ssh /var/spool/cron \
  -newer /path/to/fluentd-config-file -type f -ls 2>/dev/null

Step 5: Review Fluentd's buffer and output files for anomalous tag values.

If Fluentd logs buffer files (in /var/log/fluentd/ or your configured buffer path), review them for tag values containing ../ or other traversal sequences that might indicate attempted exploitation:

strings /path/to/fluentd/buffer/* | grep '\.\.'

Quick-Win Checklist

  • Checked Fluentd version across all instances, containers, and Kubernetes DaemonSets
  • Upgraded to Fluentd 1.19.3 on all affected deployments
  • Searched for ${tag} in file path configurations and assessed exposure
  • Verified Monitor Agent API (port 24220) is restricted from untrusted networks, or disabled if not needed
  • Audited credentials exposed by Monitor Agent API and rotated any leaked secrets
  • Inspected cron directories and SSH authorized_keys for unauthorized files written via CVE-2026-44024
  • Confirmed Fluentd process user does not run as root unless strictly necessary (least privilege)

Sources