Strimzi Kafka Operator CVE-2026-55225
HIGH
GHSA-mw9r-p8xp-wx96
Severity by source
AV:A/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H
Kubernetes API is network-reachable so AV:N; only namespace tenant rights needed (PR:L); scope changes across namespaces (S:C) with full Secret read/write (C:H/I:H) but no direct availability impact.
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H
Lifecycle Timeline
2DescriptionGitHub Advisory
Impact
Having the Topic and User operators to watch different namespaces than the one where the Kafka cluster is deployed, is a fully documented feature.
When 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.
An 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).
Patches
The 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.
Workarounds
A 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.
AnalysisAI
Cross-namespace privilege escalation in Strimzi Kafka Operator versions up to 1.0.0 allows tenants with namespace-scoped Kafka custom resource creation rights to read and write Secrets in any namespace where the Cluster Operator has been granted permissions. By abusing the documented watchedNamespace field within Kafka.spec.entityOperator, an attacker mints a token for the entity operator ServiceAccount in their own namespace and gains full CRUD on Secrets in the target namespace. …
Unlock full vulnerability intelligence
- Risk assessment & exploitation conditions
- Attack chain visualization
- Remediation with exact patch versions
- Threat intelligence from 22 sources
- Personal watchlist & email alerts
Free forever · No credit card required
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata
Vulnerability AssessmentAI
| Exploitation | Attacker must have permission to create Kafka custom resources in at least one namespace on the cluster and the ability to mint a token for a ServiceAccount in that same namespace (the entity operator SA the operator provisions). … Additional conditions and limiting factors are described in the full assessment. |
| Risk Assessment | The vendor CVSS 3.1 vector CVSS:3.1/AV:A/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H scores 8.0 High and reflects an adjacent (in-cluster) attacker with low privileges (rights to create Kafka CRs in some namespace) who can change scope to compromise Secrets in other namespaces with high CIA impact. … Full risk analysis with EPSS, KEV, and SSVC signal comparison available after sign-in. |
| Exploit Scenario | A developer with rights to create Kafka custom resources in their own tenant namespace authors a Kafka CR setting `spec.entityOperator.topicOperator.watchedNamespace: kube-system` (or any other namespace the Cluster Operator has rights into). The Cluster Operator dutifully creates a Role granting full CRUD on Secrets in `kube-system` and binds it to the entity operator ServiceAccount in the attacker's namespace; the attacker then runs `kubectl create token` against that ServiceAccount and uses the resulting token to read or overwrite Secrets - for example exfiltrating cloud provider credentials or planting backdoor TLS material. |
| Remediation | Vendor-released patch: upgrade Strimzi to 1.0.1 or 1.1.0, per advisory GHSA-mw9r-p8xp-wx96 (https://github.com/strimzi/strimzi-kafka-operator/security/advisories/GHSA-mw9r-p8xp-wx96); these versions introduce a dedicated Cluster Operator environment variable that gates the watched-namespace feature and disables it by default, so after upgrading verify you do not need to explicitly re-enable the feature for any legitimate consumers. … Detailed patch versions, workarounds, and compensating controls in full report. |
Recommended ActionAI
Within 24 hours: Identify all Strimzi Kafka Operator deployments, document versions and cluster tenancy model, and assess which instances run version 1.0.0 or earlier in multi-tenant environments. …
Sign in for detailed remediation steps and compensating controls.
Threat intelligence, references, and detailed analysis are available after sign-in.
Same weakness CWE-269 – Improper Privilege Management
View allSame technique Privilege Escalation
View allVendor StatusVendor
Share
External POC / Exploit Code
Leaving vuln.today