CVE-2026-27134

HighCVSS 8.1

Published: 21/02/2026(UTC)Updated: 15/07/2026(UTC)Translated: 16/07/2026(UTC)NVD NIST

Exploitation Probability (EPSS)

Low risk

0.37%

29th 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

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.

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.