CVE-2026-44160: Fluentd DOS Vulnerability

CVE-2026-44160 Overview

CVE-2026-44160 is a denial-of-service vulnerability in Fluentd, the open source data collector used to unify log and event ingestion across files, databases, cloud services, and Hadoop. The flaw affects the in_http and in_forward plugins, which accept gzip-compressed payloads. Fluentd enforces size limits on the compressed input through body_size_limit and chunk_size_limit, but does not bound the decompressed output. Attackers can submit small, crafted gzip payloads that expand to excessive sizes in memory, exhausting available RAM and crashing the process. The issue is fixed in Fluentd 1.19.3. The vulnerability is tracked under [CWE-409: Improper Handling of Highly Compressed Data (Data Amplification)].

Critical Impact
A remote, unauthenticated attacker can trigger memory exhaustion in Fluentd collectors by sending compressed payloads that decompress to an unbounded size, disrupting log pipelines feeding SIEM, observability, and compliance systems.

Affected Products

Fluentd versions prior to 1.19.3 running the in_http input plugin
Fluentd versions prior to 1.19.3 running the in_forward input plugin
Deployments accepting gzip-compressed event payloads from untrusted network sources

Discovery Timeline

2026-07-08 - CVE-2026-44160 published to NVD
2026-07-08 - Last updated in NVD database
Fluentd 1.19.3 - Fix released via GitHub Release v1.19.3 and GHSA-j9cw-hwqf-85w7

Technical Details for CVE-2026-44160

Vulnerability Analysis

Fluentd's HTTP and forward input plugins accept gzip-compressed event streams to reduce network overhead. The pre-patch code applies body_size_limit and chunk_size_limit only to the compressed byte count received over the wire. Decompression proceeds without any ceiling on the output buffer size, so a highly compressible payload (for example, a stream of repeated null bytes) can expand by ratios of 1,000:1 or higher. A few megabytes on the wire can allocate multiple gigabytes in the Ruby process heap. Sustained requests drive the collector into swap or trigger the OOM killer. Because Fluentd sits at the ingestion edge of most logging pipelines, an outage blocks downstream log analytics and can create observability gaps that mask concurrent attacks.

Root Cause

The root cause is missing enforcement of a decompression size limit inside the CompressedMessagePackEventStream and buffer chunk code paths. The patch introduces a new decompression_size_limit parameter (defaulting to Fluent::Plugin::Compressable::DEFAULT_DECOMPRESSION_SIZE_LIMIT) that is threaded through the event stream and file buffer constructors. Decompression is aborted once the limit is reached instead of allocating unbounded memory.

Attack Vector

Exploitation requires only network access to a Fluentd endpoint accepting compressed input. No authentication or user interaction is needed. An attacker sends an HTTP POST to an in_http listener, or a forward-protocol message to in_forward, containing a gzip payload with a very high compression ratio. Repeated requests amplify the impact until the collector process exhausts memory.

ruby

  end

  class CompressedMessagePackEventStream < MessagePackEventStream
-    def initialize(data, cached_unpacker = nil, size = 0, unpacked_times: nil, unpacked_records: nil, compress: :gzip)
+    def initialize(data, cached_unpacker = nil, size = 0, unpacked_times: nil, unpacked_records: nil, compress: :gzip, decompression_size_limit: Fluent::Plugin::Compressable::DEFAULT_DECOMPRESSION_SIZE_LIMIT)
      super(data, cached_unpacker, size, unpacked_times: unpacked_times, unpacked_records: unpacked_records)
      @decompressed_data = nil
      @compressed_data = data
      @type = compress
+      @decompression_size_limit = decompression_size_limit
    end

    def empty?

Source: Fluentd commit f5f2b7c. The patch adds the decompression_size_limit argument to the compressed event stream constructor and propagates it to the file buffer chunk generator in lib/fluent/plugin/buf_file.rb.

Detection Methods for CVE-2026-44160

Indicators of Compromise

Sudden growth in resident memory of the fluentd or ruby process handling in_http or in_forward traffic
Fluentd process restarts, OOM killer entries in dmesg, or systemd oom-killed service state
HTTP POST requests to Fluentd endpoints with Content-Encoding: gzip and small Content-Length values immediately preceding memory spikes
Gaps in downstream log ingestion coinciding with Fluentd availability loss

Detection Strategies

Compare compressed payload size against decompressed size at a reverse proxy or WAF in front of Fluentd and alert on ratios above a defined threshold
Monitor Fluentd process RSS and Ruby heap metrics via Prometheus process_resident_memory_bytes or equivalent
Track HTTP 5xx response rates and connection resets on in_http listeners as a proxy for backend collapse
Correlate Fluentd restarts with inbound request patterns from a single source IP or ASN

Monitoring Recommendations

Ingest Fluentd host telemetry and process metrics into a centralized analytics platform for baseline comparison
Alert on OOM kill events targeting Fluentd across the fleet within a short time window, which suggests coordinated abuse
Log the Content-Encoding, Content-Length, and source IP of every request hitting in_http for post-incident analysis

How to Mitigate CVE-2026-44160

Immediate Actions Required

Upgrade Fluentd to version 1.19.3 or later on all collectors exposing in_http or in_forward
Restrict network reachability of Fluentd input ports to trusted sources using firewall rules, security groups, or service mesh policy
Place a reverse proxy in front of in_http that enforces a maximum decompressed body size and rejects excessive compression ratios
Set per-process memory limits (systemd MemoryMax, container resources.limits.memory) so a single collector failure does not cascade

Patch Information

The fix is available in Fluentd 1.19.3, released via GitHub Release v1.19.3. Details are documented in GHSA-j9cw-hwqf-85w7 and implemented in Pull Request #5393 and commit f5f2b7c. The patch adds a decompression_size_limit option that bounds decompressed payload size in both in_http and buffer chunks.

Workarounds

Disable gzip acceptance on in_http by rejecting requests with Content-Encoding: gzip at an upstream proxy until the patch is applied
Bind in_forward and in_http to loopback or internal interfaces only, and require mutual TLS with client certificates for external senders
Deploy Fluentd behind a rate-limiter that throttles requests per source IP to slow amplification attempts

bash

# Verify installed Fluentd version and upgrade via RubyGems
fluentd --version
gem install fluentd -v '>= 1.19.3'

# Example systemd hardening for the fluentd service
# /etc/systemd/system/fluentd.service.d/override.conf
[Service]
MemoryMax=2G
MemoryHigh=1500M
Restart=on-failure

# Example NGINX guard in front of in_http
# nginx.conf
client_max_body_size 8m;
location /fluentd/ {
    proxy_pass http://127.0.0.1:9880/;
    if ($http_content_encoding = "gzip") { return 415; }
}