GPU VulnDB

Database/Control plane, storage & DevOps

Logging operator: unescaped Flow CRD values inject Fluentd directives and run commands in the aggregator

CVSS 9.9CVE-2026-54680Control plane, storage & DevOpscurated

Impact

Anyone allowed to create a Flow custom resource can put raw Fluentd configuration into a field such as a record_transformer records value; the renderer writes it into fluent.conf without escaping, so an injected <match **> block with @type exec runs arbitrary commands inside the Fluentd aggregator pod. On a shared GPU cluster the log aggregator is a cross-tenant component: it holds the pipeline's output credentials (object store, SIEM, log vendor tokens) and sees every tenant's logs, so a namespace-scoped tenant who can write a Flow reaches data and secrets well outside their namespace. NVD scores it 9.9 with a changed scope for exactly that reason. Log delivery is also a dependency of the operator's own audit trail, so an attacker in the aggregator can shape what the fleet records about them.

Who can reach it

Authenticated Kubernetes user or service account with permission to create or edit Flow/ClusterFlow resources in any watched namespace. No cluster-admin and no node access needed.

What to do

Upgrade the logging operator to 6.6.0, which escapes CRD-supplied strings before rendering fluent.conf; the operator rolls out a regenerated config and restarts the Fluentd aggregator, so this is a controller and daemon restart with a short log-delivery gap, not a node drain. Until then, restrict who can create Flow and ClusterFlow resources via RBAC and review existing Flow definitions for injected directives, and rotate any credentials referenced by the output configuration if you find one.

References

Related entries

All Control plane, storage & DevOps entries

This entry is curated: imported from vendor advisories with machine assistance, not yet individually verified. Confirm against your vendor's advisory before acting, and report anything wrong.