CVE-2026-27134
HighCVSS 8.1Exploitation Probability (EPSS)
Low risk29th percentile - higher than 29% of all known CVEs
Summary
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.
Risk Assessment
The risk is unauthorized access to the Kafka cluster by individuals holding certificates signed by any CA in the chain, potentially leading to data confidentiality and integrity breaches.
Recommendation
Immediately upgrade to version 0.50.1. As a temporary workaround, provide only the single CA that should be used instead of the full CA chain.
Other vulnerabilities in Strimzi
See all- CVE-2026-105312Critical
A Kubernetes tenant with create permission on Console custom resources can set spec.containers.api.spec.image to an arbitrary container image. The operator deploys this image into a pod whose ServiceAccount is bound via ClusterRoleBinding to a ClusterRole granting cluster-wide get/list/watch on all Strimzi CRDs (including KafkaUsers), patch on Kafkas/KafkaRebalances, and cluster-monitoring-view. The attacker's code reads the projected SA token and gains cross-tenant Strimzi control-plane read+write access.
- 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-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-2026-55225High
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.
Original NVD description (English source)
Strimzi provides a way to run an Apache Kafka cluster on Kubernetes or OpenShift in various deployment configurations. In versions 0.49.0 through 0.50.0, when using a custom Cluster or Clients CA with a multistage CA chain consisting of multiple CAs, Strimzi incorrectly configures the trusted certificates for mTLS authentication on the internal as well as user-configured listeners. All CAs from the CA chain will be trusted. And users with certificates signed by any of the CAs in the chain will be able to authenticate. This issue affects only users using a custom Cluster or Clients CA with a multistage CA chain consisting of multiple CAs. It does not affect users using the Strimzi-managed Cluster and Clients CAs. It also does not affect users using custom Cluster or Clients CA with only a single CA (i.e., no CA chain with multiple CAs). This issue has been fixed in version 0.50.1. To workaround this issue, instead of providing the full CA chain as the custom CA, users can provide only the single CA that should be used.
Vulnerability data from NVD (NIST) · CISA KEV · EPSS