Flux Operator, Privilege Escalation, CVE-2026-23990 (Medium)

By /

Listen to this Post

The Flux Operator, a Kubernetes CRD controller for managing CNCF Flux CD, contains a privilege escalation vulnerability in its Web UI authentication code, affecting versions 0.36.0 to 0.39.0. The issue arises when the operator is configured with an OIDC provider that issues tokens lacking expected claims (like `email` or groups) or when custom CEL expressions are configured to evaluate these claims. After the OIDC token claims are processed through these CEL expressions, the resulting `username` and `groups` values are not validated to ensure they are non-empty. When both values are empty due to missing claims or faulty CEL logic, the Kubernetes `client-go` library does not add impersonation headers to the subsequent API requests. Consequently, instead of the requests being executed with the authenticated user’s limited RBAC permissions, they are executed with the elevated privileges of the `flux-operator` service account. This allows an authenticated user to bypass RBAC impersonation and gain operator-level read access, enabling them to view sensitive GitOps configurations, source URLs, and deployment status across all namespaces. They could also potentially perform suspend, resume, or reconcile actions on Flux resources. The vulnerability requires the specific misconfiguration of OIDC claims or CEL expressions to be present. The issue is resolved in Flux Operator version 0.40.0, which introduces strict validation for RBAC impersonation fields .
Platform: Flux Operator
Version: 0.36.0-0.39.0
Vulnerability: Privilege escalation
Severity: Medium (5.3)
Date: January 21, 2026

Prediction: Patch already available

(end of form)

What Undercode Say:

Analytics

The vulnerability stems from a missing validation check after OIDC claims are processed via CEL (Common Expression Language). The core flaw is that when the CEL expressions return empty strings for `username` and groups, the `client-go` impersonation config is nil, defaulting to the pod’s service account. This is a logic error in the authentication middleware. Attack complexity is high due to the prerequisite OIDC misconfiguration.
To check your current Flux Operator version in a cluster:

Check the Flux Operator deployment's image tag
kubectl get deployment flux-operator -n <namespace> -o jsonpath="{.spec.template.spec.containers[bash].image}"

To inspect the vulnerable web configuration for empty CEL expressions:

Check the Config custom resource for the web UI
kubectl get config -n <namespace> -o yaml | grep -A5 "impersonation:"

To audit historical API requests that may have been escalated, you can query Kubernetes audit logs for requests made by the `flux-operator` service account from a user origin:

This is a conceptual query for a logging system like Loki or Elasticsearch
{log_type="kube-audit"} | json | user.username="system:serviceaccount:<namespace>:flux-operator" and annotations."authentication.k8s.io/username"!=""

To test if your current configuration is vulnerable (conceptual, do not run on production):

Attempt to list resources across namespaces after authenticating with a token that yields empty claims
kubectl get pods --all-namespaces --as="" --as-group="" --token=<your_test_token>

If this command succeeds where a normal user should not have permissions, the impersonation bypass is present.

How Exploit:

  1. Precondition: Cluster admin configures Flux Operator with an OIDC provider that does not issue `groups` claims, or uses custom CEL expressions that default to empty values.
  2. Authenticate: Attacker obtains a valid token from the misconfigured OIDC provider.
  3. Bypass: The attacker uses this token to authenticate to the Flux Operator Web UI. The CEL expressions evaluate to empty `username` and `groups` because the expected claims are missing.
  4. Escalate: The `client-go` library, receiving empty impersonation details, does not add `Impersonate-User` or `Impersonate-Group` headers. The request is executed with the `flux-operator` service account’s token.
  5. Access: The attacker can now perform any action that the `flux-operator` service account is authorized to do, such as listing all Flux custom resources in the cluster .

Protection from this CVE

  • Patch: Upgrade the Flux Operator to version `v0.40.0` or later .
  • Workaround/Mitigation: Modify the Flux Operator’s web configuration to enforce that the `groups` claim is required and non-empty. Ensure your CEL expressions in the `impersonation` section have fallback logic or validation to never result in an empty value .
  • Detection: Monitor for API requests originating from the Flux Operator Web UI pod that lack impersonation headers but perform high-privilege actions. Set up alerts for the `user.username` being the `flux-operator` service account while the request source is the web UI.

Impact

  • Privilege Escalation: Any authenticated user can escalate their privileges to match those of the `flux-operator` service account.
  • Data Exposure: Unauthorized read access to sensitive GitOps pipeline configurations, source URLs, and deployment status across all namespaces, bypassing all RBAC restrictions.
  • Cluster Integrity: Potential for unauthorized actions like suspending critical sync operations or forcing reconciliations, leading to instability or unintended deployments .

🎯Let’s Practice Exploiting & Learn Patching For Free:

Sources:

Reported By: nvd.nist.gov
Extra Source Hub:
Undercode

🔐JOIN OUR CYBER WORLD [ CVE News • HackMonitor • UndercodeNews ]

💬 Whatsapp | 💬 Telegram

📢 Follow DailyCVE & Stay Tuned:

𝕏 formerly Twitter 🐦 | @ Threads | 🔗 Linkedin Previous

PinchTab, Server-Side Request Forgery (SSRF), CVE-2026-30834 (High)

Scroll to Top