Strimzi is an open-source operator that facilitates running Apache Kafka clusters on Kubernetes or OpenShift. Between versions 0.47.0 and before 0.50.1, a vulnerability (CVE-2026-27133) exists in the certificate validation logic for Kafka Connect and Kafka MirrorMaker 2 operands. When a trusted certificate configuration includes a chain of multiple Certificate Authority (CA) certificates, the operator incorrectly trusts each CA certificate in the chain individually rather than only the final root CA. This improper validation means that server certificates signed by any intermediate CA in the chain are accepted as valid when connecting to Kafka brokers. The flaw stems from CWE-295 (Improper Certificate Validation) and CWE-296 (Improper Authentication). The vulnerability could allow an attacker with access to a certificate signed by an intermediate CA in the chain to impersonate a Kafka broker or intercept traffic, undermining confidentiality and integrity of Kafka communications. Exploitation requires network access and privileges to configure or influence Kafka Connect or MirrorMaker 2 operands but does not require user interaction. The vulnerability has a CVSS v3.1 base score of 5.9 (medium severity), reflecting the moderate complexity and impact. The issue was resolved in Strimzi version 0.50.1 by correcting the certificate validation logic to trust only the last CA in the chain. No known exploits are reported in the wild at this time.

This vulnerability impacts the security of Kafka clusters deployed via Strimzi on Kubernetes or OpenShift, specifically affecting Kafka Connect and Kafka MirrorMaker 2 components. By improperly trusting all CAs in a chain, attackers who can present a certificate signed by an intermediate CA could impersonate Kafka brokers or intercept and manipulate Kafka traffic. This compromises confidentiality and integrity of data streams, potentially leading to data leakage, unauthorized data modification, or disruption of Kafka-based applications. Organizations relying on Kafka for critical messaging or event streaming could face significant operational and reputational damage if exploited. The vulnerability requires some level of privilege and network access, limiting remote exploitation but still posing a risk in multi-tenant or less controlled environments. The absence of known exploits reduces immediate risk but does not eliminate the threat, especially as Kafka is widely used globally in financial services, telecommunications, and cloud-native applications.

To mitigate this vulnerability, organizations should upgrade Strimzi Kafka Operator to version 0.50.1 or later, where the certificate validation logic is corrected. Until upgrade is possible, administrators should audit and restrict the CA chains used in Kafka Connect and MirrorMaker 2 configurations, ensuring only trusted root CAs are included and intermediate CAs are carefully controlled. Implement network segmentation and strict access controls to limit who can configure or influence Kafka Connect and MirrorMaker 2 operands. Monitor Kafka broker certificates and connections for anomalies that could indicate misuse of intermediate CA certificates. Employ mutual TLS authentication with strict certificate pinning where feasible. Regularly review and update Kubernetes and OpenShift security policies to reduce privilege escalation risks. Finally, maintain up-to-date logging and alerting on Kafka connection events to detect potential exploitation attempts early.