{"id":"CVE-2026-55225","aliases":["EUVD-2026-78883","GHSA-mw9r-p8xp-wx96"],"status":"published","title":"Strimzi: Cross-namespace privilege escalation via `Kafka.spec.entityOperator`","description":"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.","severity":{"version":"3.1","score":8,"vector":"CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"high","assessor":"cna","from":"cve"},"epss":{"day":"2026-11-11","score":0.00295,"percentile":0.2237,"model":"v2026.06.15"},"facts":{"in_kev":false,"known_exploited":false,"public_exploit":false,"fix_available":true},"cwes":["CWE-250","CWE-269","CWE-441"],"published":"2026-06-18T13:04:43Z","modified":"2026-10-28T11:09:58Z","fixes":[{"ecosystem":"Maven","package":"io.strimzi:strimzi","fixed_in":["1.0.1"],"sources":["ghsa","osv"]}],"affected":[{"source":"ghsa","ecosystem":"Maven","package":"io.strimzi:strimzi","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"last_affected":"1.0.0"},{"fixed":"1.0.1"}]}]},{"source":"osv","ecosystem":"Maven","package":"io.strimzi:strimzi","ranges":[{"type":"ECOSYSTEM","events":[{"introduced":"0"},{"fixed":"1.0.1"}]}],"versions":["0.10.0","0.11.0","0.11.1","0.11.2","0.11.3","0.11.4","0.12.0","0.12.1","0.12.2","0.13.0","0.14.0","0.15.0","0.16.0","0.16.1","0.16.2","0.17.0","0.18.0","0.19.0","0.20.0","0.20.1","0.21.0","0.21.1","0.22.0","0.22.1","0.23.0","0.24.0","0.25.0","0.26.0","0.26.1","0.27.0","0.27.1","0.28.0","0.29.0","0.30.0","0.31.0","0.31.1","0.32.0","0.33.0","0.33.1","0.33.2","0.34.0","0.35.0","0.35.1","0.36.0","0.36.1","0.37.0","0.38.0","0.39.0","0.40.0","0.41.0","0.42.0","0.43.0","0.44.0","0.45.0","0.45.1","0.45.1-RC1","0.45.2","0.45.2-RC1","0.46.0","0.46.1","0.46.1-RC1","0.47.0","0.47.0-RC1","0.48.0","0.48.0-RC1","0.49.0","0.49.0-RC1","0.49.0-RC2","0.49.1","0.49.1-RC1","0.50.0","0.50.0-RC1","0.50.1","0.50.1-RC1","0.51.0","0.51.0-RC1","0.51.0-RC2","0.9.0","1.0.0","1.0.0-RC1","1.0.0-RC2"]}],"products":[{"vendor":"red hat","product":"streams for apache kafka 2"},{"vendor":"red hat","product":"streams for apache kafka 3.2.1"},{"vendor":"strimzi","product":"strimzi-kafka-operator"}],"references":[{"url":"https://github.com/strimzi/strimzi-kafka-operator/security/advisories/GHSA-mw9r-p8xp-wx96","tags":["x_refsource_CONFIRM","advisory","web"]},{"url":"https://github.com/strimzi/strimzi-kafka-operator/pull/12844","tags":["x_refsource_MISC","fix"]},{"url":"https://github.com/strimzi/strimzi-kafka-operator/commit/b3bfeffcc30754c3e62e6f4afd8a76942cac440d","tags":["x_refsource_MISC","fix"]},{"url":"https://github.com/strimzi/strimzi-kafka-operator/commit/f6c5207ba7ec89b46ce6720b8638d647e556a261","tags":["x_refsource_MISC","fix"]},{"url":"https://github.com/strimzi/strimzi-kafka-operator/releases/tag/1.0.1","tags":["x_refsource_MISC","web"]},{"url":"https://github.com/strimzi/strimzi-kafka-operator/releases/tag/1.1.0","tags":["x_refsource_MISC","web"]},{"url":"https://access.redhat.com/security/cve/CVE-2026-55225","tags":["vdb-entry","x_refsource_REDHAT","advisory"]},{"url":"https://bugzilla.redhat.com/show_bug.cgi?id=2490275","tags":["issue-tracking","x_refsource_REDHAT","report"]},{"url":"https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-55225.json","tags":["x_sadp-csaf-vex","web"]},{"url":"https://access.redhat.com/errata/RHSA-2026:54435","tags":["vendor-advisory","x_refsource_REDHAT","advisory"]},{"url":"https://github.com/advisories/GHSA-mw9r-p8xp-wx96"},{"url":"https://github.com/CVEProject/cvelistV5/tree/main/cves/2026/55xxx/CVE-2026-55225.json","tags":["advisory"]},{"url":"https://nvd.nist.gov/vuln/detail/CVE-2026-55225","tags":["advisory"]},{"url":"https://github.com/strimzi/strimzi-kafka-operator","tags":["package"]}],"sources":{"cve":[{"id":"CVE-2026-55225","title":"Strimzi: Cross-namespace privilege escalation via `Kafka.spec.entityOperator`","description":"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.","status":"published","published":"2026-09-15T17:15:51.236Z","modified":"2026-09-16T12:04:21.53Z","cvss":[{"version":"3.1","score":8,"vector":"CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"high","assessor":"cna"},{"version":"3.1","score":8,"vector":"CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"high","assessor":"adp"}],"cwes":["CWE-269","CWE-441","CWE-250"],"updated_at":"2026-11-02T14:20:11.925815Z"}],"euvd":[{"id":"EUVD-2026-78883","description":"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.","status":"published","published":"2026-09-15T17:15:51Z","modified":"2026-09-16T12:04:21Z","cvss":[{"version":"3.1","score":8,"vector":"CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"high"}],"updated_at":"2026-11-02T17:28:16.201278Z"}],"ghsa":[{"id":"GHSA-mw9r-p8xp-wx96","title":"Strimzi: Cross-namespace privilege escalation via `Kafka.spec.entityOperator`","description":"### Impact\n\nHaving the Topic and User operators to watch different namespaces than the one where the Kafka cluster is deployed, is a fully documented feature.\n\nWhen the `watchedNamespace` field is used within the Topic or User operator (as part of the `Kafka.spec.entityOperator` field), the Cluster Operator creates a Role granting full CRUD on Secrets into the specified namespace. It also creates a RoleBinding to bind such Role to the entity operator ServiceAccount within the namespace where the Kafka cluster runs.\n\nAn attacker can craft a Kafka custom resource (in an attacker's namespace) with the `watchedNamespace` field set to a target namespace and then they can mint a token for the ServiceAccount (in the attacker's namespace)  to read/write Secrets in that target. This is valid with any target namespace for which the Cluster Operator has the rights (regardless the value of the  `STRIMZI_NAMESPACE` environment variable). The at-risk target namespaces are the namespaces which the user has given permissions to the Cluster Operator for, by creating related RoleBinding(s).\n\n### Patches\n\nThe issue is fixed in Strimzi 1.0.1 and 1.1.0 by adding a control to enable the watched namespace feature through a dedicated environment variable within the Cluster Operator deployment. The watched namespaces feature is disabled by default.\n\n### Workarounds\n\nA possible workaround for this issue is about using a policy agent like Kyverno or OPA to prevent the usage of the `watchedNamespace` at configuration level within the `Kafka` custom resource.","status":"published","published":"2026-06-18T13:04:43Z","modified":"2026-06-18T13:04:44Z","cvss":[{"version":"3.1","score":8,"vector":"CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"high"}],"cwes":["CWE-269","CWE-441"],"updated_at":"2026-11-02T14:40:28.438722Z"}],"nvd":[{"id":"CVE-2026-55225","description":"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.","status":"published","published":"2026-09-15T18:17:23.667Z","modified":"2026-09-30T17:43:24.057Z","cvss":[{"version":"3.1","score":8,"vector":"CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"high","assessor":"secondary"},{"version":"3.1","score":8,"vector":"CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"high","assessor":"secondary"}],"cwes":["CWE-269","CWE-441","CWE-250"],"updated_at":"2026-11-02T14:12:47.668237Z"}],"osv":[{"id":"CVE-2026-55225","title":"Strimzi: Cross-namespace privilege escalation via `Kafka.spec.entityOperator`","description":"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.","status":"published","published":"2026-09-15T17:15:51.236Z","modified":"2026-10-28T11:09:58.581270592Z","cvss":[{"version":"3.1","score":8,"vector":"CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"high"}],"cwes":["CWE-269","CWE-441"],"updated_at":"2026-11-02T15:45:11.22012Z"},{"id":"GHSA-mw9r-p8xp-wx96","title":"Strimzi: Cross-namespace privilege escalation via `Kafka.spec.entityOperator`","description":"### Impact\n\nHaving the Topic and User operators to watch different namespaces than the one where the Kafka cluster is deployed, is a fully documented feature.\n\nWhen the `watchedNamespace` field is used within the Topic or User operator (as part of the `Kafka.spec.entityOperator` field), the Cluster Operator creates a Role granting full CRUD on Secrets into the specified namespace. It also creates a RoleBinding to bind such Role to the entity operator ServiceAccount within the namespace where the Kafka cluster runs.\n\nAn attacker can craft a Kafka custom resource (in an attacker's namespace) with the `watchedNamespace` field set to a target namespace and then they can mint a token for the ServiceAccount (in the attacker's namespace)  to read/write Secrets in that target. This is valid with any target namespace for which the Cluster Operator has the rights (regardless the value of the  `STRIMZI_NAMESPACE` environment variable). The at-risk target namespaces are the namespaces which the user has given permissions to the Cluster Operator for, by creating related RoleBinding(s).\n\n### Patches\n\nThe issue is fixed in Strimzi 1.0.1 and 1.1.0 by adding a control to enable the watched namespace feature through a dedicated environment variable within the Cluster Operator deployment. The watched namespaces feature is disabled by default.\n\n### Workarounds\n\nA possible workaround for this issue is about using a policy agent like Kyverno or OPA to prevent the usage of the `watchedNamespace` at configuration level within the `Kafka` custom resource.","status":"published","published":"2026-06-18T13:04:43Z","modified":"2026-06-18T13:26:29.892173Z","cvss":[{"version":"3.1","score":8,"vector":"CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H","level":"high"}],"cwes":["CWE-269","CWE-441"],"updated_at":"2026-11-02T15:46:52.534897Z"}]}}