Detect Kube-logging Logging Operator Fluentd Configuration Injection RCE (CVE-2026-54680) in Google Chronicle
Detects exploitation of CVE-2026-54680, a critical (CVSS 9.9) configuration injection vulnerability in kube-logging logging-operator (versions prior to the 0.0.0-20260608145523-cf437d7f1e05 pseudo-version / 6.6.0 release) that allows an attacker with the ability to influence Fluentd/Fluent Bit configuration inputs (e.g. via Flow/ClusterFlow/Output CRDs, log forwarding pipelines, or unsanitized log fields reflected into config templates) to inject arbitrary Fluentd configuration directives. This injection can lead to remote code execution via Fluentd's exec plugin, ruby code blocks, or file-based output writes, potentially compromising the logging-operator pod and any Kubernetes service account/token it holds, enabling lateral movement and cluster compromise.
MITRE ATT&CK
YARA-L Detection Query
rule cve_2026_54680_fluentd_config_injection {
meta:
author = "df00tech"
description = "Detects Fluentd configuration injection via logging-operator CRDs consistent with CVE-2026-54680"
severity = "critical"
cve = "CVE-2026-54680"
events:
$audit.metadata.event_type = "USER_RESOURCE_UPDATE_CONTENT"
$audit.target.resource.resource_subtype = /(?i)(flow|clusterflow|output|clusteroutput|logging)/
$audit.metadata.product_event_type = /(?i)(create|update|patch)/
$audit.target.resource.attribute.labels.raw_config = /(?i)(exec_filter|<exec>|<script>|ruby\s+do|system\(|\/bin\/(sh|bash))/
match:
$audit over 10m
outcome:
$risk_score = 95
$mitre_technique_id = "T1210"
condition:
$audit
}Chronicle YARA-L rule matching Kubernetes audit events where a Flow/ClusterFlow/Output/Logging resource is created or modified with raw configuration content containing Fluentd exec, script, or ruby injection payloads, mapping to CVE-2026-54680.
Data Sources
Required Tables
False Positives & Tuning
- Legitimate infrastructure-as-code deployments configuring exec-based Fluentd outputs
- Chronicle UDM parsers that partially populate raw_config with benign plugin metadata
- Test/staging environments exercising exec plugin functionality for approved use cases
Other platforms for CVE-2026-54680
Testing Methodology
Validate this detection against 3 adversary techniques from Atomic Red Team. Each test below lists the behaviour to exercise and the telemetry you should expect to see. Executable commands and cleanup steps are available with Pro.
- Test 1Inject exec directive via ClusterFlow CRD
Expected signal: Kubernetes audit log entries for create operations on ClusterFlow and ClusterOutput resources containing an 'exec' block, followed by fluentd operator reconciliation logs regenerating the rendered configuration.
- Test 2Inject ruby eval block into Output configuration
Expected signal: Audit log capturing the Output resource creation with enableRuby=true and a system() call embedded in the record template; fluentd pod logs showing plugin reconfiguration.
- Test 3Simulate command execution artifact from compromised fluentd pod
Expected signal: Container runtime/EDR process execution events for /bin/sh, id, whoami, and cat commands executed inside the fluentd pod, plus Kubernetes audit log entry for the 'pods/exec' subresource.
References (4)
- https://github.com/kube-logging/logging-operator/security/advisories/GHSA-mjqf-28ph-426h
- https://github.com/kube-logging/logging-operator/commit/cf437d7f1e056c78740bf5716ac8bdebcf002425
- https://github.com/kube-logging/logging-operator/releases/tag/6.6.0
- https://github.com/advisories/GHSA-mjqf-28ph-426h
Response Playbook
Triage
- Identify all namespaces and clusters running logging-operator versions prior to the patched pseudo-version (< 0.0.0-20260608145523-cf437d7f1e05, i.e. before release 6.6.0) using image tag inventory or `kubectl get pods -A -o jsonpath` against the operator image.
- Review recent create/update/patch operations on Flow, ClusterFlow, Output, ClusterOutput, and Logging custom resources via Kubernetes audit logs to identify who or what submitted the change and whether the requester is an expected service account or user.
- Inspect the raw configuration content of flagged CRDs for exec, exec_filter, script, or ruby blocks and shell metacharacters that do not match approved output plugin templates used by the organization.
- Check logging-operator and fluentd/fluent-bit pod logs for parse errors, unexpected process spawns, or crash-loop behavior that may indicate a failed or successful injection attempt.
- Determine whether any downstream Fluentd/Fluent Bit worker pods executed injected commands by correlating pod exec events, unexpected outbound network connections, or new process creation within the logging namespace.
Containment
- Immediately upgrade logging-operator to release 6.6.0 or later (commit cf437d7f1e05 or newer) in all affected clusters; if immediate upgrade is not possible, restrict write access to Flow/ClusterFlow/Output/ClusterOutput/Logging CRDs to a minimal set of trusted service accounts via RBAC.
- Quarantine or delete any Flow/ClusterFlow/Output resources found containing injected exec/ruby/script directives, and restart affected fluentd/fluent-bit pods to clear any loaded malicious configuration.
- Revoke or rotate the Kubernetes service account token and any cloud IAM credentials mounted into the logging-operator and fluentd pods, since a successful RCE could expose these credentials for lateral movement.
Evidence Collection
- Export the full Kubernetes audit log entries (with request and response bodies) for all create/update/patch operations on the affected CRDs, preserving timestamps, source IPs, and authenticated identity for forensic timeline reconstruction.
- Capture a copy of the rendered Fluentd/Fluent Bit configuration files from affected pods (e.g. via `kubectl cp` or persistent volume snapshot) before remediation, along with pod logs and any core dumps if the process crashed.
- Collect network flow logs and DNS query logs from the logging namespace to identify any command-and-control or data exfiltration activity that may have resulted from RCE.
Escalation Criteria
- !Escalate to incident response leadership if evidence shows the injected configuration successfully executed the exec plugin or ruby eval block, indicating confirmed RCE rather than a failed/blocked attempt.
- !Escalate immediately if the logging-operator service account or associated pod credentials had access to sensitive namespaces, secrets, or cluster-admin-equivalent RBAC bindings, as this represents a potential path to full cluster compromise.
- !Escalate if the affected cluster ingests logs from multiple tenants or business units, since a single compromised logging pipeline could expose data or provide lateral movement across otherwise isolated workloads.
Investigation Guide
Related Techniques
Forensic Artifacts
- >
Kubernetes audit log entries for Flow/ClusterFlow/Output/ClusterOutput/Logging resource mutations - >
Rendered fluentd.conf / fluent-bit.conf files generated by the operator and mounted into worker pods - >
Container runtime logs and process execution history within logging-operator and fluentd/fluent-bit pods - >
Kubernetes service account token usage logs from the cluster's API server audit trail
Tuning Guidance
Baseline legitimate uses of Fluentd exec, exec_filter, and ruby plugins within the organization (some teams intentionally use these for custom log enrichment) and add an allowlist of approved namespaces, service accounts, or CI/CD pipeline identities that are permitted to deploy such configurations. Tune out known GitOps reconciliation bots by filtering on the authenticated `user.username` field, and increase severity when the requester identity does not match the expected set of automation accounts or when the injected content includes network calls, credential access commands, or reverse shell patterns.
Hunting Queries
Long-window (30-day) historical hunt for any historical Flow/ClusterFlow/Output/Logging CRD mutations containing exec/ruby/shell directives, to determine whether exploitation attempts predate detection deployment.
KubernetesConfigLog
| where TimeGenerated > ago(30d)
| where ObjectKind in ("Flow", "ClusterFlow", "Output", "ClusterOutput", "Logging")
| extend ConfigContent = tostring(RequestObject)
| where ConfigContent has_any ("exec", "ruby", "system(", "/bin/sh", "/bin/bash")
| summarize count() by Namespace, ObjectKind, bin(TimeGenerated, 1d)index=kubernetes sourcetype="kube:audit" (kind="Flow" OR kind="ClusterFlow" OR kind="Output") | regex requestObject="(?i)(exec|ruby|system\(|/bin/(sh|bash))" | timechart span=1d count by namespaceAtomic Red Team Tests
Simulates an attacker with CRD write access creating a ClusterFlow resource containing an injected Fluentd exec directive to test detection of CVE-2026-54680-style configuration injection in a lab cluster.
Command
kubectl apply -f - <<'EOF'
apiVersion: logging.banzaicloud.io/v1beta1
kind: ClusterFlow
metadata:
name: atomic-test-exec-injection
namespace: logging
spec:
filters:
- tagNormaliser: {}
globalOutputRefs:
- test-exec-output
EOF
kubectl apply -f - <<'EOF'
apiVersion: logging.banzaicloud.io/v1beta1
kind: ClusterOutput
metadata:
name: test-exec-output
namespace: logging
spec:
exec:
command: id
format:
type: json
EOFCleanup
kubectl delete clusterflow atomic-test-exec-injection -n logging --ignore-not-found; kubectl delete clusteroutput test-exec-output -n logging --ignore-not-foundExpected Telemetry
Kubernetes audit log entries for create operations on ClusterFlow and ClusterOutput resources containing an 'exec' block, followed by fluentd operator reconciliation logs regenerating the rendered configuration.
Expected Detection
KQL/SPL/EQL rules matching 'exec' directive injection into Flow/Output CRDs should trigger an alert referencing the atomic-test-exec-injection ClusterFlow.
Tests whether monitoring detects an injected ruby code block within an Output CRD's record_transformer or similar plugin, simulating an attacker attempting to achieve RCE via ruby evaluation as described in the CVE-2026-54680 advisory.
Command
kubectl apply -f - <<'EOF'
apiVersion: logging.banzaicloud.io/v1beta1
kind: Output
metadata:
name: atomic-test-ruby-output
namespace: logging
spec:
recordTransformer:
enableRuby: true
records:
- test_field: "${system('id')}"
EOFCleanup
kubectl delete output atomic-test-ruby-output -n logging --ignore-not-foundExpected Telemetry
Audit log capturing the Output resource creation with enableRuby=true and a system() call embedded in the record template; fluentd pod logs showing plugin reconfiguration.
Expected Detection
Chronicle/QRadar rules scanning requestObject content for 'ruby' and 'system(' patterns should flag the atomic-test-ruby-output resource.
After a successful (simulated) injection, this test spawns a shell command from within a fluentd worker container to validate that downstream process-execution telemetry (EDR/container runtime) correlates with the earlier configuration injection audit event.
Command
kubectl exec -n logging deploy/fluentd -- /bin/sh -c 'id; whoami; cat /run/secrets/kubernetes.io/serviceaccount/token | head -c 20; echo'Cleanup
No persistent changes made; no cleanup required beyond ensuring the exec session is closed.Expected Telemetry
Container runtime/EDR process execution events for /bin/sh, id, whoami, and cat commands executed inside the fluentd pod, plus Kubernetes audit log entry for the 'pods/exec' subresource.
Expected Detection
Correlation rule (e.g. Elastic EQL sequence) linking the earlier CRD injection audit event to this subsequent pod exec/process execution activity within a 10-minute window should trigger a high-confidence alert.