Strimzi: Cross-namespace privilege escalation via `Kafka.spec.entityOperator`
Default status is the baseline for the product, each version can override it (e.g. patched versions marked unaffected).
| Vendor | Product | Default status | Versions | ||||||
|---|---|---|---|---|---|---|---|---|---|
| strimzi | strimzi-kafka-operator | affected |
|
No data.
No data.
| Vendor | Product | Versions | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| Strimzi | Kafka-operator |
|
| Source | ID | Title |
|---|---|---|
Github GHSA |
GHSA-mw9r-p8xp-wx96 | Strimzi: Cross-namespace privilege escalation via `Kafka.spec.entityOperator` |
No CVSS v4.0
No CVSS v3.0
No CVSS v2
This CVE is not in the KEV list.
Exploit prediction score: < 1% (0.295% probability within 30 days)
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
| Type | Values Removed | Values Added |
|---|---|---|
| Description | When the Strimzi cluster operator is deployed with watchAnyNamespace=true (or a multi-namespace list), any namespace editor can set Kafka.spec.entityOperator.userOperator.watchedNamespace (or topicOperator.watchedNamespace) to an arbitrary namespace. The cluster operator then creates a Role granting full CRUD on Secrets in the target namespace and a RoleBinding pointing to a ServiceAccount in the attacker's namespace — effectively granting cluster-admin-equivalent access via kube-system secret exfiltration. The RBAC objects created cross-namespace have their ownerReferences deliberately stripped, making the privilege grant persistent even after the Kafka CR or attacker namespace is deleted. Fixed in Strimzi 1.0.1 and 1.1.0 by adding a dedicated environment variable to explicitly enable the watched namespace feature (disabled by default). | Strimzi provides a way to run an Apache Kafka cluster on Kubernetes or OpenShift in various deployment configurations. In Strimzi 1.0.0 and earlier, an attacker who can create a Kafka custom resource can set Kafka.spec.entityOperator watchedNamespace to a target namespace, causing the Cluster Operator to create a Role with full Secret CRUD permissions there and bind it to the Entity Operator ServiceAccount in the attacker's namespace. The attacker can mint a token for that ServiceAccount and read or write Secrets in any target namespace where the Cluster Operator has been granted permissions, regardless of STRIMZI_NAMESPACE. This issue is fixed in versions 1.0.1 and 1.1.0. |
| Title | strimzi-cluster-operator: Cross-namespace privilege escalation via Kafka.spec.entityOperator.watchedNamespace in Strimzi | Strimzi: Cross-namespace privilege escalation via `Kafka.spec.entityOperator` |
| Weaknesses | CWE-269 CWE-441 |
|
| References |
|
|
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Strimzi
Strimzi kafka-operator |
|
| Vendors & Products |
Strimzi
Strimzi kafka-operator |
| Type | Values Removed | Values Added |
|---|---|---|
| Description | When the Strimzi cluster operator is deployed with watchAnyNamespace=true (or a multi-namespace list), any namespace editor can set Kafka.spec.entityOperator.userOperator.watchedNamespace (or topicOperator.watchedNamespace) to an arbitrary namespace. The cluster operator then creates a Role granting full CRUD on Secrets in the target namespace and a RoleBinding pointing to a ServiceAccount in the attacker's namespace — effectively granting cluster-admin-equivalent access via kube-system secret exfiltration. The RBAC objects created cross-namespace have their ownerReferences deliberately stripped, making the privilege grant persistent even after the Kafka CR or attacker namespace is deleted. Fixed in Strimzi 1.0.1 and 1.1.0 by adding a dedicated environment variable to explicitly enable the watched namespace feature (disabled by default). | |
| Title | strimzi-cluster-operator: Cross-namespace privilege escalation via Kafka.spec.entityOperator.watchedNamespace in Strimzi | |
| Weaknesses | CWE-250 | |
| References |
| |
| Metrics |
threat_severity
|
cvssV3_1
|