EUVD-2026-78880
GHSA-r427-j2h7-wv3m
Severity by source
AV:A/AC:H/PR:L/UI:N/S:U/C:H/I:L/A:N
Cluster-adjacent access (AV:A) with a non-default partial-deployment trigger (AC:H/PR:L); Secrets exposure drives C:H; no availability impact.
Primary rating from Vendor (https://github.com/strimzi/strimzi-kafka-operator).
CVSS VectorVendor: https://github.com/strimzi/strimzi-kafka-operator
Lifecycle Timeline
2DescriptionCVE.org
Impact
When only the Topic or only the User operators are deployed as part of the Entity Operator in the Kafka custom resource, the RBAC rights are not following the principle of least-privilege and the Entity Operator ServiceAccount still has access rights corresponding to both operators. That might allow the ServiceAccount to access KafkaUser custom resources and Secrets when the User operator is not deployed and access KafkaTopic custom resources when the Topic operator is not deployed.
Patches
The issue is fixed in Strimzi 1.0.1 and 1.1.0.
Workarounds
There is no workaround for this issue.
AnalysisAI
Strimzi Kafka Operator versions 1.0.0 and earlier provision the Entity Operator ServiceAccount with combined RBAC rights for both the Topic Operator and User Operator regardless of which sub-operators are actually enabled in the Kafka custom resource, violating the principle of least privilege. When only one of the two sub-operators is deployed, the overly permissive ServiceAccount can access KafkaUser custom resources and namespace Secrets (when the User Operator is absent) or KafkaTopic custom resources (when the Topic Operator is absent). No public exploit has been identified at time of analysis and the vulnerability is not listed in the CISA KEV catalog; however, the High confidentiality impact (C:H) due to potential Secret access elevates the urgency of patching.
Technical ContextAI
Strimzi is a CNCF-graduated Kubernetes operator for running Apache Kafka, distributed as the Maven artifact io.strimzi:strimzi. Its Entity Operator component manages two sub-operators: the Topic Operator (reconciles KafkaTopic CRDs) and the User Operator (reconciles KafkaUser CRDs and their associated Kubernetes Secrets, which typically contain credentials and TLS material). Each sub-operator requires distinct Kubernetes RBAC Role or ClusterRole bindings. The root cause (CWE-269: Improper Privilege Management) is that the Entity Operator ServiceAccount is statically provisioned with the union of both sub-operators' RBAC permissions, independent of the actual runtime configuration declared in the Kafka custom resource. When an administrator deploys only the Topic Operator, the ServiceAccount nonetheless retains the User Operator's rights - including GET, LIST, and WATCH on Secrets and KafkaUser objects - creating a privilege surface far wider than the active workload requires.
RemediationAI
Upgrade to Strimzi 1.0.1 or 1.1.0, the vendor-confirmed fixed releases per GitHub Security Advisory GHSA-r427-j2h7-wv3m (https://github.com/strimzi/strimzi-kafka-operator/security/advisories/GHSA-r427-j2h7-wv3m). The vendor explicitly states no workaround exists. As a compensating control while upgrade is planned, security teams can audit and manually scope down the Entity Operator ServiceAccount's RBAC Role or ClusterRole bindings to remove permissions for resources managed by the absent sub-operator - for example, removing Secrets and KafkaUser access when the User Operator is not deployed. This manual RBAC tightening carries the trade-off of potential reconciliation failures if the deployment configuration changes and the permissions are not restored before re-enabling the missing sub-operator. Additionally, consider using Kubernetes NetworkPolicies to restrict egress from the Entity Operator pod to only the API server endpoints it legitimately requires, reducing the utility of excessive permissions to an attacker who has compromised the pod.
Same weakness CWE-269 – Improper Privilege Management
View allSame technique Privilege Escalation
View allVendor StatusVendor
Share
External POC / Exploit Code
Leaving vuln.today