Bug 2483943 (CVE-2026-10609)

Summary: CVE-2026-10609 openshift/cluster-logging-operator: Cluster Logging Operator creates and forwards ServiceAccount tokens without verifying CLF creator authorization
Product: [Other] Security Response Reporter: OSIDB Bzimport <bzimport>
Component: vulnerabilityAssignee: Product Security DevOps Team <prodsec-dev>
Status: NEW --- QA Contact:
Severity: medium Docs Contact:
Priority: medium    
Version: unspecifiedCC: jcantril, rojacob, security-response-team
Target Milestone: ---Keywords: Security
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: ---
Doc Text:
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.
 Story Points: ---
Clone Of: Environment:
Last Closed: Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Deadline: 2026-06-23   

Description OSIDB Bzimport 2026-06-02 12:01:24 UTC 
A flaw was found in the OpenShift Cluster Logging Operator. The operator creates kubernetes.io/service-account-token Secrets and forwards them as bearer authentication to output URLs without verifying that the ClusterLogForwarder creator has authorization to use the referenced ServiceAccount's credentials. A user with write access to ClusterLogForwarder resources but without secrets access can exfiltrate ServiceAccount tokens for any in-namespace ServiceAccount. When a CLF specifies only receiver-type inputs, the SubjectAccessReview validation is bypassed entirely, widening the attack to SAs without log-collection RBAC. However, even with standard inputs, any SA that passes the input-side SAR check (including the operator's own SA) has its token created and forwarded without output-side authorization. The stolen token inherits all RBAC bindings of the target ServiceAccount, potentially enabling cluster-wide privilege escalation.