Fluentd Hit by Unauthenticated RCE (CVE-2026-44024, CVSS 9.8) Plus 5 More — Update to v1.19.3 Now

Fluentd, the popular open-source software for collecting the floods of logs that servers and apps produce, has serious vulnerabilities. The worst lets an attacker overwrite arbitrary files on the server without any authentication, simply by crafting the source of a log, ultimately leading to remote code execution. Tracked as CVE-2026-44024, it carries the maximum CVSS score of 9.8 out of 10. The maintainers released a fix on June 26, 2026, and in Japan, JVN (JVN#36011274) issued an advisory on June 29.

This is not the only issue disclosed. Information disclosure that exposes the contents of configuration files, denial of service (DoS) that takes the service down, and server-side request forgery (SSRF) that makes Fluentd talk to attacker-controlled servers were all patched together — six vulnerabilities in total. Fluentd is widely used for log collection in container platforms such as Kubernetes and is a "graduated" project of the CNCF (Cloud Native Computing Foundation). The wider the deployment, the wider the potential blast radius.

Scores above are from NVD (CVSS v3.1). Under CVSS v4.0 as used by JVN, some scores differ (CVE-2026-44024 is 9.3).

Who is at risk, and what could happen

The most dangerous issue, CVE-2026-44024, threatens anyone running Fluentd so that it accepts logs from external — or not-fully-trusted internal — sources, where an attacker can feed in crafted logs. For example, a setup that ingests logs over an internet-facing endpoint, or a SaaS-style configuration where many tenants or apps send logs into the same Fluentd, lets an attacker pose as a legitimate sender. No login (authentication) is needed.

From there, the attacker slips path-traversal characters such as ../ into the log's "tag," and overwrites files in system locations Fluentd should never touch. Fluentd can build output file paths from the tag value, and when that value is poorly validated, configuration files or scheduled-task mechanisms can be overwritten, leading to full server takeover. The maintainers state that this flaw directly enables remote code execution (running attacker-supplied programs on the server).

The core danger is that the logging backend flips from "the thing that watches" into "the way in." A log-collection server is a junction where data from many systems converges; once it is seized, attackers can steal credentials contained in stored logs, pivot to other systems, and tamper with logs to erase their tracks. The other five issues — disclosure of passwords or tokens written into config files (CVE-2026-44025), DoS that stops Fluentd and therefore your logs (CVE-2026-44160 and others) — all strike at the foundations of operations. Fluentd is plumbing that never appears in your application's source code, and weaknesses in such foundations cast a shadow over the whole supply chain. Our OSS supply-chain scanner piece covers why it matters to audit the vulnerabilities of the software you depend on.

What is Fluentd

Fluentd is open-source software that acts like a "log dispatch center": it takes logs that servers, apps, and network gear emit in many different formats, unifies them into a single stream, and routes them to destinations (files, Amazon S3, search backends, monitoring services, and so on). It was born in 2011 at Treasure Data in Japan and is now developed with the help of ClearCode and others. Its hallmark is flexible input/output via "plugins," with hundreds of plugins published.

Adoption is broad worldwide; it is a staple for log collection in Kubernetes environments and, together with the lightweight "Fluent Bit," holds a huge share. These vulnerabilities affect not only Fluentd itself but also the output plugins fluent-plugin-s3 and fluent-plugin-opentelemetry, and the distribution package fluent-package. The first step is taking stock of which components, at which versions, you actually run.

The six vulnerabilities, one by one

CVE-2026-44024: tag-based file overwrite to remote code execution (most critical, CVSS 9.8)

This is the centerpiece. Fluentd can dynamically build output file paths from a log's "tag" (the ${tag} placeholder). Because path-traversal characters such as ../ are insufficiently validated, an attacker can write and overwrite files anywhere, which directly leads to remote code execution (RCE). No authentication is required; setups that use out_file (or similar) with ${tag} while ingesting logs from untrusted sources are at risk. Reported by everping; fixed in Fluentd 1.19.3.

CVE-2026-44025: monitor API leaks sensitive config data (CVSS 7.5)

Fluentd's monitoring API (the monitor agent) lacks proper authentication, so sensitive information in configuration files (such as credentials for destinations) can be read via the API. The impact is greater when passwords or tokens are written directly into the config.

CVE-2026-44161: SSRF via a plugin (CVSS 7.2)

By abusing placeholder expansion, an attacker can make Fluentd send requests to servers it should not reach (SSRF), or trigger a DoS. It affects fluent-plugin-opentelemetry and is fixed in 0.5.3. The risk is that it becomes a stepping stone to areas not directly reachable from outside, such as cloud metadata endpoints.

CVE-2026-44160 / 44163 / 44162: denial of service via decompression

Three issues abuse flaws in decompression handling to overload and stop Fluentd. CVE-2026-44160 is a DoS via a "decompression bomb" (a small compressed blob that expands to an enormous size), CVSS 7.5; CVE-2026-44163 is a DoS via large payloads, CVSS 5.3; CVE-2026-44162 is a DoS that requires admin privileges, CVSS 2.7. When logs stop, monitoring stops too — a secondary effect that can blind you to other attacks. These relate to Fluentd itself and to fluent-plugin-s3 (fixed in 1.8.5).

Affected versions and fixes (quick reference)

For exact affected and fixed ranges, see JVN#36011274 and each GitHub Security Advisory. Because fluent-package bundles the core and plugins, updating it as a whole is the safest path.

What to do now

The top priority is updating to fixed versions. Move the core to Fluentd 1.19.3, fluent-plugin-s3 to 1.8.5, and fluent-plugin-opentelemetry to 0.5.3. If you run the distribution package (fluent-package), update the whole package to the latest, since it contains the core and plugins together.

If you cannot update immediately, the maintainers list these interim workarounds: restrict ingestion from the internet and untrusted paths with a firewall; run Fluentd as a non-root user (to limit the blast radius); avoid using ${tag} in output paths; and filter incoming tags, rejecting any that contain . or /. Also, if you hard-code credentials in config files, move them to environment variables or a secrets manager, and keep the monitoring API off limits from the outside — which also helps against the information-disclosure issue, CVE-2026-44025.

If your organization runs Fluentd or Fluent packages across many servers, first inventory which hosts run which versions, and prioritize closing the ingestion endpoints that receive logs from outside.

In closing

Of the six fixes, CVE-2026-44024 is the serious one: crafting a log tag is enough to overwrite files without authentication and reach full server takeover. The fact that log collection — the unglamorous plumbing — can become an entry point makes this hard to dismiss. The core is fixed in 1.19.3, and fixed releases exist for the plugins and packages, so the priority is to inventory your environment and update.

The more widely a foundational piece of software is used, the larger the impact of a single hole. The logging backend you rarely think about is a good occasion to revisit version management and privilege minimization.

FAQ

References

• ・JVN — JVN#36011274 (multiple vulnerabilities in Fluentd)
• ・GitHub Security Advisory — GHSA-44hj-4m45-frj3 (CVE-2026-44024)
• ・Fluentd — Security Advisories
• ・NVD — CVE-2026-44024
• ・Fluentd — v1.19.3 release notes
• ・CNCF — Fluentd project