CVE-2026-55225
HighCVSS 8.0Summary
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. Fixed in versions 1.0.1 and 1.1.0.
Risk Assessment
An attacker able to create Kafka resources can access Secrets in any namespace where the Cluster Operator has permissions, potentially leading to privilege escalation and compromise of the entire cluster. This may result in exposure of sensitive data and takeover of infrastructure.
Recommendation
Upgrade Strimzi to version 1.0.1 or 1.1.0, which fix this vulnerability. Until patched, consider restricting the ability of unprivileged users to create Kafka resources and audit Cluster Operator permissions.
Other vulnerabilities in Strimzi
See all- CVE-2026-55226Medium
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, deploying only the Topic Operator or only the User Operator through the Kafka custom resource leaves the Entity Operator ServiceAccount with RBAC permissions for both components. The excess permissions can allow access to KafkaUser custom resources and Secrets when the User Operator is absent, or access to KafkaTopic custom resources when the Topic Operator is absent.
- CVE-2024-36543Critical
Incorrect access control in the Kafka Connect REST API in Strimzi Project 0.41.0 and earlier allows an attacker to perform DoS on Kafka Mirroring, potentially mirror topics' content to their own Kafka cluster (bypassing Kafka ACLs), and steal Kafka SASL credentials by querying the MirrorMaker Kafka REST API.
- CVE-2026-27134High
A vulnerability in Strimzi versions 0.49.0 through 0.50.0 involves incorrect configuration of trusted certificates for mTLS authentication when using a custom CA with a multistage CA chain. This causes all CAs in the chain to be trusted, allowing users with certificates signed by any CA in the chain to authenticate.
Original NVD description (English source)
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.