Strimzi Kafka Operator facilitates running Apache Kafka clusters on Kubernetes and OpenShift. In versions 0.49.0 through 0.50.0, a critical authentication flaw exists when users configure a custom Cluster or Clients Certificate Authority (CA) using a multistage CA chain (multiple CAs). The operator incorrectly configures trusted certificates for mutual TLS (mTLS) authentication on both internal and user-configured listeners by trusting all CAs in the chain indiscriminately. This means that any client certificate signed by any CA in the chain is accepted, effectively broadening trust beyond the intended single CA. This improper authentication (CWE-287) can allow unauthorized clients to connect to Kafka brokers, potentially leading to full compromise of confidentiality, integrity, and availability of the Kafka cluster. The vulnerability is specific to custom CA chains and does not affect users relying on Strimzi-managed CAs or single-CA custom configurations. The flaw was addressed in Strimzi version 0.50.1 by correcting the trusted certificate configuration to restrict trust appropriately. Until upgrading, users can mitigate risk by providing only the single CA intended for authentication rather than the full CA chain. The CVSS 3.1 base score is 8.1 (high), reflecting network attack vector, no privileges or user interaction required, and high impact on confidentiality, integrity, and availability. No public exploits have been reported to date.

This vulnerability allows unauthorized entities possessing certificates signed by any CA in the multistage chain to authenticate to Kafka brokers managed by Strimzi, bypassing intended authentication controls. The impact is severe because it compromises the confidentiality, integrity, and availability of Kafka clusters, potentially allowing attackers to read sensitive data streams, inject malicious messages, or disrupt service. Organizations relying on Strimzi with custom CA chains face risks of data breaches, service outages, and lateral movement within Kubernetes or OpenShift environments. Given Kafka's role in critical data pipelines and event streaming, exploitation could affect business operations, compliance, and trust. The vulnerability does not require user interaction or privileges, increasing exploitation ease. However, it only affects deployments using custom multistage CA chains, limiting scope somewhat. The absence of known exploits suggests limited current exploitation but the high severity score indicates urgent remediation is warranted.

1. Upgrade Strimzi Kafka Operator to version 0.50.1 or later, where the vulnerability is fixed. 2. If immediate upgrade is not feasible, reconfigure custom Cluster or Clients CA settings to provide only the single CA certificate intended for authentication, not the full multistage CA chain. 3. Audit existing Kafka deployments to identify use of custom multistage CA chains and verify authentication configurations. 4. Implement strict certificate issuance policies to limit trusted CAs and monitor certificate usage. 5. Employ network segmentation and access controls to restrict Kafka broker access to trusted clients. 6. Monitor Kafka logs and network traffic for anomalous authentication attempts or unexpected client certificates. 7. Regularly review and update Kubernetes/OpenShift cluster security posture to reduce attack surface. 8. Consider deploying additional authentication layers or mutual TLS verification outside Strimzi if feasible.