Technical impact
An attacker who can create a Kafka custom resource is able to set the entityOperator.watchedNamespace field to any target namespace. The operator then creates a Role that grants full create, read, update, and delete permissions on Secrets in that namespace and binds it to the Entity Operator ServiceAccount that belongs to the attacker's namespace. Because the attacker can obtain a token for that ServiceAccount, they can read or write Secrets in the target namespace, regardless of the originally intended broker namespace. This constitutes cross‑namespace privilege escalation that allows the attacker to access sensitive data such as passwords or certificates. The weakness involves improper access control, insecure default permissions, and untrusted input, reflected in CWE‑250, CWE‑269 and CWE‑441. The likely attack vector is that an attacker must already possess the permission to create Kafka custom resources, typically requiring cluster‑level or namespace‑editor rights – this prerequisite is inferred from the description rather than explicitly stated.
Affected Systems
Strimzi Kafka Operator versions 1.0.0 and earlier, running on Kubernetes or OpenShift clusters, are affected. Versions 1.0.1 and 1.1.0 contain the fix and are not vulnerable.
Risk and Exploitability
The CVSS score of 8.0 classifies this as a high‑severity vulnerability. The EPSS indicates a probability of less than 1 %, so widespread exploitation is considered unlikely, and the vulnerability is not listed in the CISA KEV catalog. Exploitation requires that the attacker already have the permission to create Kafka custom resources; no additional network exposure or vulnerability is necessary. Once the Role is created the privileges persist even if the attacker’s namespace is removed, meaning the escalation is durable.
Github GHSA