CVE-2026-55225: 
Java vulnerability analysis and mitigation

CVE-2026-55225 is a cross-namespace privilege escalation vulnerability in the Strimzi Cluster Operator that allows namespace editors to gain cluster-admin-equivalent access via RBAC manipulation. When the operator is deployed with watchAnyNamespace=true or a multi-namespace list, an attacker with namespace-editor privileges can set Kafka.spec.entityOperator.userOperator.watchedNamespace (or topicOperator.watchedNamespace) to an arbitrary target namespace, causing the Cluster Operator to create a Role granting full CRUD on Secrets in that namespace. The vulnerability affects Strimzi versions ≤ 1.0.0 and was disclosed on June 17, 2026, with patches released in versions 1.0.1 and 1.1.0. It carries a CVSS v3.1 base score of 8.0 (High) (Github Advisory, Strimzi Advisory).

The root cause is improper privilege management (CWE-269) and a confused deputy problem (CWE-441), where the Strimzi Cluster Operator acts as an unintended intermediary that creates cross-namespace RBAC objects on behalf of an attacker-controlled Kafka custom resource. When the watchedNamespace field is set in Kafka.spec.entityOperator, the Cluster Operator creates a Role granting full CRUD on Secrets in the specified namespace and a RoleBinding pointing to the entity operator's ServiceAccount in the attacker's namespace — effectively delegating access to the attacker. Critically, 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. The attack is valid for any namespace the Cluster Operator has been granted permissions to, regardless of the STRIMZI_NAMESPACE environment variable value (Strimzi Advisory, Github Advisory).

Successful exploitation grants the attacker read/write access to Secrets in any target namespace the Cluster Operator has permissions over, including kube-system, enabling exfiltration of service account tokens, TLS certificates, and other sensitive credentials that can be leveraged for full cluster compromise. The scope change (S:C) in the CVSS score reflects that the impact extends beyond the attacker's own namespace to other namespaces across the cluster. Because the malicious RBAC objects persist after cleanup of the Kafka CR or attacker namespace (due to stripped ownerReferences), the privilege grant survives remediation attempts that do not explicitly remove the orphaned Role and RoleBinding objects (Strimzi Advisory, Feedly).

1. Reconnaissance: Identify a Kubernetes cluster running Strimzi Cluster Operator ≤ 1.0.0 with watchAnyNamespace=true or a multi-namespace watch configuration, and confirm you have namespace-editor privileges in at least one watched namespace.
2. Identify target namespace: Determine a high-value target namespace (e.g., kube-system) for which the Cluster Operator has been granted permissions via existing RoleBindings.
3. Craft malicious Kafka CR: Create a Kafka custom resource in your attacker-controlled namespace with Kafka.spec.entityOperator.userOperator.watchedNamespace or topicOperator.watchedNamespace set to the target namespace:

apiVersion: kafka.strimzi.io/v1beta2
kind: Kafka
metadata:
  name: attacker-kafka
  namespace: attacker-namespace
spec:
  entityOperator:
    userOperator:
      watchedNamespace: kube-system

4. Wait for RBAC object creation: The Cluster Operator processes the Kafka CR and automatically creates a Role granting full CRUD on Secrets in kube-system and a RoleBinding binding it to the entity operator ServiceAccount in the attacker's namespace.
5. Mint a ServiceAccount token: Generate a token for the entity operator ServiceAccount in the attacker's namespace using kubectl create token or by creating a Secret of type kubernetes.io/service-account-token.
6. Exfiltrate secrets: Use the minted token to authenticate to the Kubernetes API and read Secrets from the target namespace (e.g., kubectl get secrets -n kube-system --token=<minted-token>), extracting credentials for further lateral movement or cluster takeover.
7. Persist access: Delete the Kafka CR or the attacker namespace; the orphaned Role and RoleBinding (with stripped ownerReferences) remain in the target namespace, preserving the privilege grant (Strimzi Advisory, Github Advisory).

• Kubernetes RBAC: Unexpected Role objects in sensitive namespaces (e.g., kube-system) granting full CRUD on Secrets, with names following Strimzi naming conventions (e.g., strimzi-<kafka-name>-entity-operator) but with no ownerReferences set.
• Kubernetes RBAC: RoleBindings in target namespaces pointing to ServiceAccounts in a different (attacker-controlled) namespace, particularly entity operator ServiceAccounts.
• Kubernetes API Audit Logs: Cluster Operator creating roles and rolebindings in namespaces outside the Kafka cluster's own namespace, especially in kube-system or other privileged namespaces.
• Kubernetes API Audit Logs: Unexpected secrets read/list/watch operations in sensitive namespaces by entity operator ServiceAccount tokens originating from a different namespace.
• Kubernetes Resources: Kafka custom resources with spec.entityOperator.userOperator.watchedNamespace or spec.entityOperator.topicOperator.watchedNamespace set to a namespace other than the Kafka cluster's own namespace.
• Kubernetes API Audit Logs: Token creation (TokenRequest) for entity operator ServiceAccounts by users who are not cluster administrators (Strimzi Advisory).

Upgrade Strimzi Cluster Operator to version 1.0.1 or 1.1.0, which fixes the issue by requiring the watched namespace feature to be explicitly enabled via a dedicated environment variable in the Cluster Operator deployment (disabled by default) (Strimzi Advisory). As a workaround for environments that cannot immediately upgrade, deploy a policy agent such as Kyverno or OPA/Gatekeeper to block the use of watchedNamespace in Kafka custom resources at admission time. Additionally, audit existing RBAC objects across all namespaces for orphaned Strimzi-created Roles and RoleBindings with no ownerReferences, and remove any that are unauthorized. Restrict Cluster Operator namespace watch scope to the minimum required namespaces rather than using watchAnyNamespace=true (Github Advisory).

The vulnerability was reported by security researcher Artem Cherezov (@cherez0ff) and remediated by Strimzi maintainers ppatierno, scholzj, and katheris (Github Advisory). Red Hat tracked the issue via Bugzilla (Bug 2490275) and published a security advisory (RHSA-2026:34608), indicating downstream impact on Red Hat products that bundle Strimzi (Red Hat Bugzilla). No significant broader media coverage or social media discussion has been identified at this time.