Logging Operator Fluentd Config Injection Enables RCE via Flow CRD (CVE-2026-54680)

A security advisory for kube-logging/logging-operator discloses a critical vulnerability (CVE-2026-54680, CVSS 9.9) in how the operator renders Fluentd configuration from Kubernetes custom resources. According to the GitHub Security Advisory (GHSA-mjqf-28ph-426h), the FluentRender function in pkg/sdk/logging/model/render/fluent.go writes string values from CRDs such as Flow directly into fluent.conf without escaping or rejecting newlines and special characters like < and >.

The advisory documents a confirmed exploitation path: a value supplied in a Flow resource's record_transformer.records field can contain embedded newlines that close the current Fluentd <record>/<filter> block and open a new <match **> block using Fluentd's built-in @type exec plugin. Because the operator's config validation only checks that the resulting configuration is syntactically valid (via fluentd --dry-run), the injected block passes and is written into the live configuration, letting an attacker execute arbitrary commands inside the Fluentd aggregator pod when matching logs are flushed. A working PoC is included in the advisory, and the researchers note that on EKS the aggregator pod may have reachability to the node's Instance Metadata Service, which could extend impact to cloud credential theft.

Why It Matters

Any tenant or user permitted to create Flow and Output resources in a namespace watched by Logging operator can potentially achieve remote code execution in the shared Fluentd aggregator — a component that typically has broad log ingestion access across the cluster's logging domain. In multi-tenant Kubernetes environments where namespace-scoped users are trusted to manage their own logging pipelines but not given cluster-wide access, this collapses that isolation boundary. The advisory reports this was confirmed on EKS, and notes the underlying command-execution primitive is not mitigated by IMDSv2 enforcement.

What Defenders Should Do Now

• Identify whether Logging operator is deployed with a Fluentd aggregator and inventory who can create or modify Flow and Output custom resources in each namespace, treating that permission as equivalent to code execution in the aggregator until patched.
• Review RBAC bindings for the logging.banzaicloud.io API group and restrict Flow/Output creation to trusted operators rather than general tenant users.
• Audit existing Flow resources and the generated Fluentd configuration Secret (fluentd.conf) for unexpected directives such as @type exec, embedded <match> blocks, or other structural anomalies that don't correspond to intended CRD definitions.
• Where feasible, monitor the Fluentd aggregator pod for anomalous outbound network activity (including requests to 169.254.169.254) and unexpected child processes spawned by the Fluentd process.
• Watch the upstream repository for a patched release and apply it once available; in the interim, consider restricting network egress from the aggregator pod and limiting IMDS access via IMDSv2-only enforcement or hop-limit controls as defense in depth.

This is a same-day disclosure and the situation is still developing — no fixed version details were included in the information reviewed here, and defenders should track the advisory directly for patch availability and further guidance. See the original GitHub Security Advisory for full technical details: GHSA-mjqf-28ph-426h.