CVE-2026-55225 in Kafka Operator
Summary
by MITRE • 09/15/2026
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.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 09/15/2026
The vulnerability identified in Strimzi versions prior to 1.0.1 and 1.1.0 represents a critical privilege escalation flaw within the Kubernetes-based deployment of Apache Kafka clusters. Strimzi is designed to simplify the operation of Kafka on container orchestration platforms by managing cluster lifecycle through custom resources. However, the specific configuration option for the Entity Operator's watched namespace allows an attacker with the ability to create or modify Kafka custom resources to manipulate the scope of permissions granted by the Cluster Operator. By setting the Kafka.spec.entityOperator.watchedNamespace parameter to a target namespace distinct from where the Strimzi components are deployed, the attacker triggers the creation of a Kubernetes Role within that target namespace. This role is configured with full Create, Read, Update, and Delete (CRUD) permissions over Secrets, which are sensitive data stores in Kubernetes containing credentials, tokens, and other confidential information.
The operational impact of this flaw is severe because it effectively bypasses namespace isolation boundaries intended to contain access within specific project or tenant spaces. Once the Cluster Operator creates the Role with broad Secret management capabilities, it binds this role to the ServiceAccount associated with the Entity Operator in the attacker's original namespace. This binding allows the attacker to mint a service account token for that compromised identity. With this token, the attacker gains authenticated access to read and write Secrets not only within their own namespace but also across any target namespace where the Cluster Operator has been granted permissions. This capability undermines the multi-tenancy model of Kubernetes environments, potentially leading to unauthorized data exfiltration or further lateral movement by compromising credentials stored in those secrets.
From a technical classification perspective, this vulnerability aligns with CWE-269, which addresses Improper Privilege Management, as it allows an actor to elevate their privileges beyond what is intended for their initial access level. It also relates to CWE-732, involving Incorrect Permission Assignment for Critical Resource, due to the overly permissive Role binding created by the operator logic. In terms of adversary tactics, this behavior corresponds to ATT&CK technique T1508, specifically Subvert Trust Controls, where an attacker exploits trust relationships between system components and services to gain unauthorized access. The flaw stems from a lack of strict validation on namespace references within custom resource definitions, allowing cross-namespace permission escalation that was not anticipated by the original security design.
Mitigation for this vulnerability requires immediate upgrading to Strimzi version 1.0.1 or later, where these issues have been addressed through stricter input validation and more restrictive default permissions. For environments unable to upgrade immediately, administrators should audit Kafka custom resources to ensure no watchedNamespace configurations point to sensitive target namespaces outside of the intended operational scope. Additionally, implementing network policies and strict Role-Based Access Control (RBAC) reviews can help limit the blast radius if such a configuration is inadvertently applied. Regular monitoring for unexpected ServiceAccount token creations or unusual Secret access patterns in Kubernetes audit logs can also aid in detecting exploitation attempts before significant damage occurs.