EUVD-2026-78883
GHSA-mw9r-p8xp-wx96
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessObtain namespace-tenant rights in target cluster
-
DeliveryCraft Kafka CR with watchedNamespace pointing at victim namespace
-
ExploitCluster Operator provisions Role and RoleBinding to entity operator SA
-
ExecutionMint ServiceAccount token in attacker namespace
-
PersistRead or modify Secrets in victim namespace
-
ImpactPivot using stolen credentials or planted material
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A06:2025 - Insecure Design
ASVS 5.0
V8 - Authorization Least privilege enforcement
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | 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). Strimzi must be running a vulnerable version (<= 1.0.0) with the documented |
| Impact | 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. AC:H is reasonable because exploitation depends on the Cluster Operator already having a RoleBinding into the target namespace, which is operator deployment-specific. There is no EPSS, no KEV listing, and no public exploit identified at time of analysis, so this is a latent multi-tenant escalation risk rather than a mass-exploited issue - however, in shared Kubernetes clusters running Strimzi the impact is essentially full read/write of any Secret (TLS keys, DB passwords, cloud credentials) in operator-reachable namespaces, which warrants priority remediation for any operator-as-a-service or multi-team deployment. SSVC data is not provided; the realistic prioritization is High for multi-tenant clusters and Medium for single-team deployments. |
| Exploit ScenarioDerived | A developer with rights to create Kafka custom resources in their own tenant namespace authors a Kafka CR setting |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jun 18, 2026
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. No public exploit identified at time of analysis, but the attack is mechanically straightforward in any multi-tenant Strimzi deployment.
RemediationAI
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. If immediate upgrade is not possible, the vendor-recommended workaround is to deploy a policy agent such as Kyverno or OPA Gatekeeper with an admission policy that rejects Kafka custom resources whose spec.entityOperator.topicOperator.watchedNamespace or spec.entityOperator.userOperator.watchedNamespace differs from the namespace of the Kafka resource itself; the trade-off is that any legitimate cross-namespace entity-operator topology will also be blocked until exceptions are written. Additionally consider tightening the Cluster Operator's cluster-wide RoleBindings so it only has rights into namespaces that truly need managed Kafka, which shrinks the blast radius of any future bypass.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in maven, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
Strimzi is the upstream operator that manages Apache Kafka on Kubernetes, packaged as the Maven artifact io.strimzi:strimzi. The Cluster Operator reconciles Kafka custom resources and, when entityOperator.topicOperator.watchedNamespace or entityOperator.userOperator.watchedNamespace is set, provisions a Role granting full CRUD on Secrets in the watched namespace plus a RoleBinding to the entity operator ServiceAccount that lives in the Kafka cluster's namespace. CWE-269 (Improper Privilege Management) applies because the operator follows the user-supplied watchedNamespace field without an additional authorization check confirming the requestor actually owns or is entitled to act on that namespace, conflating the operator's cluster-wide permissions with the tenant's legitimate scope. The vulnerability is therefore not a code-injection or auth-bypass bug but a design flaw in how cross-namespace Role provisioning is authorized.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
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 Vendor (https://github.com/strimzi/strimzi-kafka-operator).
CVSS VectorVendor: https://github.com/strimzi/strimzi-kafka-operator
DescriptionCVE.org
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.
Executive ViewAI
Strimzi Kafka Operator versions up to 1.0.0 contain a cross-namespace privilege escalation vulnerability (CVE-2026-55225) that allows cluster users with basic Kafka resource creation rights to read and write Kubernetes Secrets across namespace boundaries in multi-tenant deployments. This breaks the security isolation expected in shared infrastructure and exposes database credentials, API keys, and configuration secrets stored in other namespaces. Organizations operating Strimzi in multi-tenant Kubernetes environments face immediate risk of credential compromise and unauthorized access to sensitive system data.
No vendor-released patch identified at time of analysis. Implement interim controls: (1) Restrict Cluster Operator ServiceAccount RBAC to minimum required namespaces via ClusterRole scope; (2) Disable or remove watchedNamespace field from Kafka custom resources to prevent cross-namespace access; (3) Restrict Kafka custom resource creation to trusted administrators only; (4) Audit and rotate all Secrets in managed namespaces; (5) Implement network policies to restrict Pod-to-Pod communication between entity operator and other namespaces; (6) Consider physical separation of multi-tenant clusters until patched.
Threat Intelligence Overview
NVD
CVE.org
EPSS
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Privilege escalation occurs when an attacker leverages flaws in access control mechanisms to gain permissions beyond what they were originally granted.
Exploit-DB