CVE-2026-27134 in strimzi-kafka-operator
Summary
by MITRE • 02/21/2026
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.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 02/27/2026
The vulnerability described in CVE-2026-27134 affects Strimzi versions 0.49.0 through 0.50.0 and relates to improper certificate trust configuration in Kubernetes-based Apache Kafka deployments. This issue specifically impacts deployments that utilize custom Cluster or Clients Certificate Authorities with multistage CA chains containing multiple certificate authorities. The flaw represents a significant security weakness in the certificate trust model implementation, where the system incorrectly accepts all certificates from the entire CA chain rather than restricting trust to the intended root authority. This misconfiguration creates an expanded trust boundary that undermines the security controls designed to limit authentication to specific trusted entities. The vulnerability falls under CWE-295 which addresses improper certificate validation, specifically the issue of trusting certificate authorities beyond the intended scope. From an operational security perspective, this weakness creates a path for unauthorized authentication where entities possessing certificates issued by any CA within the chain can gain access to the Kafka cluster, effectively bypassing the intended security boundaries.
The technical implementation flaw occurs in how Strimzi processes certificate trust configurations when custom CA chains are provided. When users configure a multistage CA chain with multiple intermediate certificate authorities, the system fails to properly isolate the trust relationships and instead configures the entire chain as trusted. This creates a scenario where any certificate signed by any authority within the chain becomes valid for mTLS authentication, regardless of whether that authority should be trusted for the specific deployment. The operational impact is substantial as it allows for privilege escalation and unauthorized access to Kafka cluster resources, potentially enabling data exfiltration, message manipulation, or denial of service attacks. The vulnerability specifically affects internal listeners and user-configured listeners, meaning both system components and user-facing endpoints become vulnerable. This issue demonstrates a failure in certificate validation logic and trust chain processing, which aligns with ATT&CK technique T1552.001 for credentials from password storage devices and T1078.004 for valid accounts through compromised credentials, as it enables unauthorized access through legitimate authentication mechanisms.
The security implications extend beyond simple access control as this vulnerability can be leveraged for lateral movement within environments where Kafka clusters are used as messaging infrastructure. Attackers could potentially exploit this weakness to establish persistent access points or to move between systems that rely on the same certificate infrastructure. The vulnerability is particularly concerning in enterprise environments where certificate management is critical for maintaining security boundaries and compliance requirements. Organizations using Strimzi with custom multistage CA chains face a significant risk of unauthorized access, especially when these chains contain intermediate authorities that should not be trusted for the specific Kafka deployment. The fix implemented in version 0.50.1 addresses this by properly enforcing certificate trust boundaries and ensuring that only the explicitly configured root CA is trusted for authentication purposes. The recommended workaround of providing only the single CA instead of the full chain serves as a temporary mitigation strategy that aligns with the principle of least privilege by limiting the trust scope to only what is necessary for operation. This vulnerability highlights the importance of proper certificate validation and trust chain management in distributed systems, particularly in containerized environments where security boundaries can be easily compromised through misconfigurations in credential handling and authentication processes.