Fluentd CVE-2026-44160
HIGH
GHSA-j9cw-hwqf-85w7
Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Unauthenticated network requests to in_http/in_forward (PR:N, AV:N, AC:L) with no UI; impact is availability-only (A:H, C:N/I:N) via OOM, no scope change.
Primary rating from Vendor (https://github.com/fluent/fluentd).
CVSS VectorVendor: https://github.com/fluent/fluentd
Lifecycle Timeline
2DescriptionCVE.org
Fluentd's in_http and in_forward plugins support receiving gzip-compressed data. While Fluentd correctly enforces size limits on the incoming compressed payloads (e.g., via body_size_limit or chunk_size_limit), it was discovered that there is no limit enforced on the size of the decompressed data.
If a Fluentd instance is exposed to untrusted networks, an attacker can send a maliciously crafted, highly compressed payload. When Fluentd attempts to decompress this payload in memory, it will expand to an excessive size, completely bypassing the intended payload size limits.
Impact
This vulnerability allows for a Denial of Service (DoS) attack via memory exhaustion. The rapid memory consumption during decompression can easily lead to an Out-of-Memory kill of the Fluentd process by the operating system. This results in the disruption of all log collection and forwarding capabilities on the affected node.
Patches
v1.19.3
Workarounds
If an immediate upgrade is not possible, users are strongly advised to apply the following mitigations:
- Restrict Network Access
- Ensure that Fluentd input ports (such as
9880forin_httpand24224forin_forward) are deployed within a closed, trusted network. Use firewall rules (e.g., iptables, AWS Security Groups) to block access from untrusted networks or instances.
- Use a Reverse Proxy
- If developers must expose HTTP ingestion to external sources, place a robust reverse proxy (such as Nginx) in front of Fluentd. Configure the proxy to handle the gzip decompression and enforce strict limits on both compressed and uncompressed body sizes before passing the traffic to Fluentd.
AnalysisAI
Denial of service in Fluentd (rubygems package, versions <= 1.19.2) lets remote attackers crash the log collector by sending a gzip decompression bomb to the in_http (default port 9880) or in_forward (default port 24224) plugins. Although Fluentd enforces body_size_limit and chunk_size_limit on the compressed payload, it applies no ceiling on the decompressed output, so a tiny crafted payload expands in memory until the OS OOM-kills the process. No public exploit identified at time of analysis and it is not in CISA KEV, but EPSS-style risk is bounded by the requirement that an input port be reachable from an untrusted network.
Technical ContextAI
Fluentd is a Ruby-based open-source log aggregation daemon (CNCF graduated project) whose in_http and in_forward input plugins accept gzip-compressed event streams to reduce bandwidth. The flaw is CWE-409 (Improper Handling of Highly Compressed Data / data amplification), the classic 'zip bomb' pattern: size validation occurs on the wire-format compressed bytes before inflation, while the in-memory inflate routine has no cap, allowing a high compression ratio (gzip can exceed 1000:1) to defeat the configured limits. The affected component is the rubygems/fluentd package; the v1.19.3 fix (notably PR #5393, 'buffer, in_http: enforce size limits on decompressed payloads') adds enforcement of size limits on the decompressed buffer so inflation is aborted once it crosses the intended threshold.
RemediationAI
Vendor-released patch: upgrade to Fluentd 1.19.3, which enforces size limits on decompressed payloads (PR #5393); see https://github.com/fluent/fluentd/releases/tag/v1.19.3 and advisory GHSA-j9cw-hwqf-85w7. If immediate upgrade is not possible, restrict network access to the input ports (9880 for in_http, 24224 for in_forward) using firewall rules such as iptables or cloud security groups so only trusted hosts can reach them - the trade-off is that any legitimate external sender must be added to the allowlist. Alternatively, place a reverse proxy such as Nginx in front of HTTP ingestion configured to perform the gzip decompression itself and enforce strict limits on both compressed and uncompressed body sizes before forwarding; the side effect is added proxy infrastructure and the need to keep its limits tuned to expected payload sizes. Do not rely on body_size_limit or chunk_size_limit as a mitigation - bypassing those is precisely the flaw.
Denial of service against HTTP/2 server implementations allows remote unauthenticated attackers to exhaust server resour
The ngx_http_parse_chunked function in http/ngx_http_parse.c in nginx 1.3.9 through 1.4.0 allows remote attackers to cau
A critical vulnerability in Kubernetes ingress-nginx controller allows unauthenticated attackers with pod network access
nginx 0.8.41 through 1.4.3 and 1.5.x before 1.5.7 allows remote attackers to bypass intended restrictions via an unescap
An issue was discovered on GL.iNet devices before version 4.5.0. Rated critical severity (CVSS 9.8), this vulnerability
Nginx versions since 0.5.6 up to and including 1.13.2 are vulnerable to integer overflow vulnerability in nginx range fi
The resolver in nginx before 1.8.1 and 1.9.x before 1.9.10 allows remote attackers to cause a denial of service (invalid
Kubernetes ingress-nginx contains a configuration injection vulnerability via the mirror-target and mirror-host Ingress
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-url` Ingres
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-tls-match-c
Roxy-WI is a web interface for managing Haproxy, Nginx, Apache and Keepalived servers. Rated critical severity (CVSS 9.8
The STARTTLS implementation in mail/ngx_mail_smtp_handler.c in the SMTP proxy in nginx 1.5.x and 1.6.x before 1.6.1 and
Same technique Denial Of Service
View allShare
External POC / Exploit Code
Leaving vuln.today