Skip to content

Fluentd is Vulnerable to Denial of Service (DoS) via Gzip Decompression Bomb in `in_http` and `in_forward`

High severity GitHub Reviewed Published Jun 26, 2026 in fluent/fluentd • Updated Jun 26, 2026

Package

bundler fluentd (RubyGems)

Affected versions

<= 1.19.2

Patched versions

1.19.3

Description

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:

  1. Restrict Network Access
    • Ensure that Fluentd input ports (such as 9880 for in_http and 24224 for in_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.
  2. 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.

References

@Watson1978 Watson1978 published to fluent/fluentd Jun 26, 2026
Published to the GitHub Advisory Database Jun 26, 2026
Reviewed Jun 26, 2026
Last updated Jun 26, 2026

Severity

High

CVSS overall score

This score calculates overall vulnerability severity from 0 to 10 and is based on the Common Vulnerability Scoring System (CVSS).
/ 10

CVSS v3 base metrics

Attack vector
Network
Attack complexity
Low
Privileges required
None
User interaction
None
Scope
Unchanged
Confidentiality
None
Integrity
None
Availability
High

CVSS v3 base metrics

Attack vector: More severe the more the remote (logically and physically) an attacker can be in order to exploit the vulnerability.
Attack complexity: More severe for the least complex attacks.
Privileges required: More severe if no privileges are required.
User interaction: More severe when no user interaction is required.
Scope: More severe when a scope change occurs, e.g. one vulnerable component impacts resources in components beyond its security scope.
Confidentiality: More severe when loss of data confidentiality is highest, measuring the level of data access available to an unauthorized user.
Integrity: More severe when loss of data integrity is the highest, measuring the consequence of data modification possible by an unauthorized user.
Availability: More severe when the loss of impacted component availability is highest.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H

EPSS score

Weaknesses

Improper Handling of Highly Compressed Data (Data Amplification)

The product does not handle or incorrectly handles a compressed input with a very high compression ratio that produces a large output. Learn more on MITRE.

CVE ID

CVE-2026-44160

GHSA ID

GHSA-j9cw-hwqf-85w7

Source code

Credits

Loading Checking history
See something to contribute? Suggest improvements for this vulnerability.