Strimzi Kafka Operator facilitates running Apache Kafka clusters on Kubernetes or OpenShift environments, supporting various deployment configurations. In versions 0.49.0 through 0.50.0, a critical vulnerability (CVE-2026-27134) was identified related to improper authentication (CWE-287) in the handling of mutual TLS (mTLS) authentication when using custom Cluster or Clients Certificate Authorities (CAs) configured as multistage CA chains. Specifically, when a multistage CA chain with multiple CAs is provided, Strimzi incorrectly configures the trusted certificates for mTLS authentication on both internal and user-configured listeners. Instead of restricting trust to a single intended CA, Strimzi trusts all CAs in the chain, effectively broadening the trust scope. This misconfiguration allows any user possessing a certificate signed by any CA in the chain to authenticate successfully, bypassing intended authentication controls. The vulnerability does not affect users who use Strimzi-managed CAs or those who configure a custom CA with only a single CA (no chain). The flaw stems from improper validation and trust boundary enforcement in the mTLS setup. The issue was addressed and fixed in Strimzi version 0.50.1. Until upgrading, users can mitigate risk by providing only the single CA intended for authentication instead of the entire CA chain. The CVSS v3.1 base score is 8.1, reflecting a high severity with network attack vector, high impact on confidentiality, integrity, and availability, and no required privileges or user interaction. No known exploits have been reported in the wild to date.

This vulnerability can have significant impact on organizations running Apache Kafka clusters managed by Strimzi on Kubernetes or OpenShift, particularly those using custom multistage CA chains for mTLS authentication. Unauthorized users with certificates signed by any CA in the chain can gain access to Kafka listeners, potentially allowing them to intercept, modify, or disrupt Kafka message streams. This compromises confidentiality, integrity, and availability of critical messaging infrastructure. Given Kafka's role in real-time data pipelines, financial transactions, telemetry, and event-driven architectures, exploitation could lead to data breaches, service disruptions, and loss of trust. The broad trust of multiple CAs increases the attack surface, especially in environments where multiple CAs are managed or delegated. Organizations relying on strict authentication boundaries may find their security controls bypassed. The vulnerability affects only a subset of users with specific CA configurations but can be critical in those contexts. The lack of known exploits suggests limited active exploitation but does not reduce the potential risk if attackers develop exploits. The high CVSS score underscores the severity and need for prompt remediation.

To mitigate this vulnerability, affected organizations should upgrade Strimzi Kafka Operator to version 0.50.1 or later where the issue is fixed. Until upgrade is possible, users should avoid supplying a full multistage CA chain as the custom Cluster or Clients CA. Instead, provide only the single CA certificate that should be trusted for mTLS authentication to restrict trust scope appropriately. Review and audit all custom CA configurations to ensure no unintended CAs are trusted. Implement strict certificate issuance policies to limit the number of trusted CAs and certificates. Monitor Kafka listener authentication logs for unusual or unexpected certificate usage. Consider additional network segmentation and access controls around Kafka clusters to reduce exposure. Employ certificate pinning or validation mechanisms where feasible to enforce strict authentication boundaries. Regularly review and update Kubernetes and OpenShift cluster security best practices to complement these mitigations. Finally, maintain awareness of vendor advisories for any further updates or patches.