Fluentd CVE-2026-44160

Exploitation requires that a vulnerable Fluentd instance (<= 1.19.2) have an in_http or in_forward listener reachable by the attacker AND that the input accept gzip-compressed data - both plugins support gzip ingestion that triggers the unbounded in-memory inflation. The CVSS vector is AV:N/AC:L/PR:N/UI:N, so no authentication or user interaction is needed once the port is reachable. The key limiting factor, per the vendor advisory, is network exposure: if the in_http (9880) / in_forward (24224) ports are confined to a closed, trusted network, localhost sidecar, or fronted by a proxy that caps decompressed size, the attack is not reachable. Impact is limited to availability (process crash / OOM) - no confidentiality or integrity effect.

The CVSS 3.1 vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (7.5 High) is internally consistent: network-reachable, low complexity, no privileges or interaction, with impact confined to availability (C:N/I:N) - appropriate for a pure DoS. The decisive real-world limiter, stated explicitly in the advisory, is that Fluentd must be 'exposed to untrusted networks'; in the common deployment where in_forward/in_http listen only on a trusted internal subnet or localhost sidecar, the practical attack surface is much smaller than AV:N alone implies. There is no EPSS or SSVC data supplied, no KEV listing, and no POC reference, so this should be triaged as a genuine but availability-only issue - prioritize where Fluentd ingestion ports face untrusted clients, and treat as lower urgency for closed-network deployments. Note the gap: CVSS marks AV:N/PR:N unconditionally, but the description conditions exploitation on network exposure - verify your own deployment's reachability before assigning priority.

An attacker who can reach an internet- or tenant-exposed Fluentd in_http (9880) or in_forward (24224) port crafts a small, extremely high-ratio gzip payload (a decompression bomb) and POSTs or forwards it. Fluentd accepts it because the compressed size is under the configured limit, then inflates it in memory until consumption spikes and the kernel OOM-kills the process, halting all log collection and forwarding on that node. No public POC is referenced, but the technique is well-understood and trivially reproducible given the low attack complexity (AC:L) and no authentication (PR:N).