Logging operator CVE-2026-54680

Exploitation requires that the Logging operator is deployed with a Fluentd aggregator pipeline (not a Fluent Bit-only setup) and that the attacker holds Kubernetes RBAC permission to create Flow and Output custom resources (logging.banzaicloud.io/v1beta1) in a namespace watched by the operator, e.g. a tenant namespace. The concrete injection uses the record_transformer filter's records field, where a value containing newlines closes the current </record>/</filter> blocks and opens a <match **> block with @type exec. Limiting factors: the attacker must already have namespace-level create rights on these CRDs (PR:L, so not fully unauthenticated), the aggregator image must include the core exec plugin (true for the official Fluentd image), and clusters where only cluster admins define logging Flows are not realistically exploitable by lower-privileged users. No end-user interaction is needed and the built-in fluentd --dry-run config check does not block the payload because it is syntactically valid.

The signals are largely consistent and point to a genuine high priority in multi-tenant clusters. The CVSS 3.1 vector (AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H, 9.9) reflects network reachability via the Kubernetes API, low complexity, only low privileges (namespace-level ability to create Flow/Output CRs), no user interaction, and a scope change because code executes in the separate, often cluster-shared Fluentd aggregator. A functional PoC in the vendor advisory raises real exploitability; publicly available exploit code exists. The key limiting factor - which the raw 9.9 obscures - is the PR:L requirement: the attacker must already be able to create Flow/Output resources in a watched namespace, so this is primarily a tenant-to-cluster privilege-escalation / trust-boundary break rather than an unauthenticated internet-facing bug. No EPSS score was provided and there is no CISA KEV entry, so there is no evidence of widespread active exploitation; treat the risk as high specifically for multi-tenant or delegated-namespace deployments and lower where only cluster admins can define logging Flows.

A tenant with permission to manage logging in namespace tenant-a creates a nullout Output, then a Flow whose record_transformer.records value embeds newlines that close the <record>/<filter> blocks and open a <match **> block with @type exec and a command of the attacker's choice. When the operator renders and the aggregator reloads the config, the injected exec plugin runs arbitrary commands inside the shared Fluentd aggregator pod, giving the attacker code execution across the logging pipeline. A complete PoC (Output + Flow manifests) is published in the GHSA advisory, making reproduction straightforward.