Metrics
Affected Vendors & Products
| Source | ID | Title |
|---|---|---|
Github GHSA |
GHSA-mw9r-p8xp-wx96 | Strimzi: Cross-namespace privilege escalation via `Kafka.spec.entityOperator` |
Solution
No solution given by the vendor.
Workaround
No workaround given by the vendor.
Tue, 15 Sep 2026 20:30:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| Metrics |
ssvc
|
Tue, 15 Sep 2026 17:30:00 +0000
| 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 |
|
|
Wed, 24 Jun 2026 16:45:00 +0000
| Type | Values Removed | Values Added |
|---|---|---|
| First Time appeared |
Strimzi
Strimzi kafka-operator |
|
| Vendors & Products |
Strimzi
Strimzi kafka-operator |
Thu, 18 Jun 2026 16:45:00 +0000
| 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
|
Projects
Sign in to view the affected projects.
Status: PUBLISHED
Assigner: GitHub_M
Published:
Updated: 2026-09-15T19:44:47.681Z
Reserved: 2026-06-16T16:16:32.628Z
Link: CVE-2026-55225
Updated: 2026-09-15T19:02:31.415Z
Status : Received
Published: 2026-09-15T18:17:23.667
Modified: 2026-09-15T20:17:20.293
Link: CVE-2026-55225
OpenCVE Enrichment
Updated: 2026-06-24T16:04:07Z
Github GHSA