MEDIUM 6.8

CVE-2026-10609: OpenShift Cluster Logging Operator Missing Authorization Vulnerability

OpenShift Cluster Logging Operator contains a flaw in how it handles ServiceAccount credentials. When an operator creates a log forwarder, it automatically generates and sends ServiceAccount tokens to external destinations without first checking whether the person setting up the forwarder should have access to those credentials. This means a delegated editor—someone with limited permissions to modify cluster configurations—could trick the system into exposing sensitive authentication tokens, then use those tokens to gain higher privileges than they should have.

Source data · NVD / CISA · public domain

CVSS
3.1 · 6.8 MEDIUM · CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:N/A:N
Weaknesses (CWE)
CWE-862
Affected products
2 configuration(s)
Published / Modified
2026-06-23 / 2026-07-08

NVD description (verbatim)

A missing authorization flaw was found in the OpenShift Cluster Logging Operator. The operator creates and forwards ServiceAccount tokens to output destinations without verifying that the ClusterLogForwarder creator has permission to use those credentials, allowing a delegated editor to exfiltrate SA tokens and escalate privileges.

2 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-10609 is a missing authorization vulnerability (CWE-862) in Red Hat's OpenShift Cluster Logging Operator. The operator fails to enforce RBAC authorization checks before forwarding ServiceAccount tokens through ClusterLogForwarder objects to configured output destinations. An authenticated user with ClusterLogForwarder creation or edit permissions can exploit this to exfiltrate ServiceAccount tokens without the operator verifying the creator's eligibility to access those credentials. This enables privilege escalation within the cluster by leveraging the permissions embedded in the forwarded tokens.

Business impact

This vulnerability creates an insider risk and privilege escalation pathway in OpenShift environments. An operator or delegated cluster editor could move laterally or escalate privileges by obtaining ServiceAccount tokens for sensitive workloads. Affected organizations lose the assurance that credential access is properly gated by role-based access control, potentially exposing infrastructure, application data, or inter-service communication. The impact is magnified in multi-tenant or federated OpenShift clusters where delegation of administrative tasks is common.

Affected systems

Red Hat Cluster Logging Operator and Red Hat Logging Subsystem for Red Hat OpenShift are affected. The vulnerability applies to instances where ClusterLogForwarder objects are used to forward logs to external or internal destinations. Clusters relying on the operator for log aggregation and forwarding are in scope if they have users with delegated editor permissions on ClusterLogForwarder resources.

Exploitability

Exploitation requires network access to the OpenShift cluster API and valid credentials with permissions to create or modify ClusterLogForwarder objects—a moderate privilege level. No user interaction is required once the forwarder is configured. The CVSS vector (PR:H) reflects that the attacker must already hold a higher-privilege account, but the impact is substantial because it bypasses intended authorization boundaries. This is not a zero-click vulnerability, but it is straightforward to execute for a delegated administrator.

Remediation

Apply security patches from Red Hat as they become available. Verify patch availability and version guidance by consulting the Red Hat security advisories and product documentation for both Cluster Logging Operator and Logging Subsystem for Red Hat OpenShift. In the interim, restrict ClusterLogForwarder creation and edit permissions to only trusted administrators, and audit existing log forwarder configurations to ensure they are not exfiltrating credentials. Monitor ServiceAccount token usage for anomalies.

Patch guidance

Consult Red Hat's official security advisories for the Cluster Logging Operator and Logging Subsystem for Red Hat OpenShift to identify patched versions. Verify the specific version numbers and release dates in those advisories before planning your patch cycle. Test patches in a non-production OpenShift environment first, as logging operators are critical path components. Plan a maintenance window to avoid disruption to log collection and forwarding during the upgrade.

Detection guidance

Monitor ClusterLogForwarder resource creation and modifications using Kubernetes audit logs. Look for forwarders created by users with elevated edit permissions that forward logs to unusual or external destinations. Use RBAC analysis tools to identify which ServiceAccounts are being exposed through active forwarders. Correlate ServiceAccount token usage in access logs with ClusterLogForwarder configurations to detect unauthorized token exfiltration. Enable audit logging at the Kubernetes API level to capture ClusterLogForwarder spec changes.

Why prioritize this

Although the CVSS score is MEDIUM (6.8), the vulnerability enables privilege escalation and credential exfiltration in Kubernetes-based infrastructure. It bypasses fundamental authorization controls and affects all log-forwarding pipelines in the cluster. In environments where ClusterLogForwarder is widely delegated (common in large enterprises), the risk surface is broad. The lack of KEV status does not reduce operational priority—patch as part of your regular security patching cadence, prioritizing systems with delegated ClusterLogForwarder permissions and sensitive ServiceAccounts exposed to forwarding.

Risk score, explained

The CVSS 3.1 score of 6.8 (MEDIUM) reflects high confidentiality impact (C:H) because ServiceAccount tokens grant access to cluster resources, but no integrity or availability impact. The complexity is low (AC:L) because no special conditions are required to trigger the flaw. The attack requires high privileges (PR:H) to set up a forwarder, but the scope is changed (S:C) because the impact extends beyond the attacker's original authorization level. This scoring is appropriate for an insider threat that breaches intended access controls.

Frequently asked questions

Can this vulnerability be exploited from outside the cluster?

No. Exploitation requires valid credentials and network access to the OpenShift cluster API. An attacker would need to authenticate as a user with ClusterLogForwarder permissions. However, compromised cluster credentials or insider threats can easily exploit this flaw.

Does this affect all ServiceAccounts in the cluster?

Only ServiceAccounts that are referenced in active ClusterLogForwarder configurations are at risk of token exfiltration. However, a malicious user with forwarder permissions could create new forwarders that target any ServiceAccount, making the scope potentially broad depending on your RBAC configuration.

What is the difference between this and a simple credential leak?

This is not just a leak—it's an authorization bypass. The operator forwards tokens without checking if the user requesting the forwarding should have access to those credentials. A delegated editor with narrow permissions could expose high-privilege ServiceAccounts they don't directly control, enabling lateral movement.

Do I need to rotate all ServiceAccount tokens if I am affected?

Yes, if you suspect log forwarders have been active and exfiltrating tokens, rotate all ServiceAccounts referenced in those forwarders. Review audit logs to determine when forwarders were created or modified and which tokens were in scope. This is especially important for high-privilege service accounts used by operators or critical applications.

This analysis is provided for informational purposes and represents the state of CVE-2026-10609 as of the published date. Patch version numbers, release dates, and availability should be verified directly with Red Hat security advisories and product documentation. Organizations should conduct their own risk assessment based on their specific OpenShift deployment, RBAC configuration, and ServiceAccount usage patterns. SEC.co does not provide legal or compliance advice. Consult your security team and vendor guidance before implementing any remediation. Source: NVD (public-domain), retrieved 2026-07-28. Analysis generated by SEC.co (claude-haiku-4-5).