Strimzi trusts all CAs in multi-CA chain for mTLS authentication
TL;DR — A Strimzi bug causes all CAs in a multi-stage certificate chain to be trusted for mTLS authentication, weakening client identity verification on Kafka listeners.
What happened
Strimzi is a CNCF sandbox project that provides operators for running Apache Kafka clusters on Kubernetes. CVE-2026-27134 describes a High-severity vulnerability in Strimzi where configuring a custom Cluster CA or Clients CA as a multi-stage chain causes Strimzi to trust all CAs in that chain for mTLS authentication, rather than only the intended root. A client certificate signed by any CA in the chain may be accepted.
This is a subtle but dangerous certificate validation mistake — it effectively widens the trust boundary for Kafka listener authentication, potentially allowing unauthorized clients if any CA in the chain issues certificates to untrusted parties.
Who is impacted
- Strimzi users running
0.49.0through0.50.0. - Deployments using a custom CA provided as a multi-CA chain.
- Applies to internal listeners and user-configured listeners using TLS client auth (mTLS).
- Not impacted: Strimzi-managed CAs or single-CA custom setups.
What to do now
- Follow vendor remediation guidance and apply the latest patched release available at the time of writing.
- If you cannot patch, use the workaround: provide only the single CA that should be trusted, not the full chain.
- Review mTLS client certificates issued from intermediate/alternate CAs and consider re-issuing if unintended trust could have existed.
Content is AI-assisted and reviewed by our team, but issues may be missed and best practices evolve rapidly, send corrections to [email protected]. Always consult official documentation and validate key implementation decisions before making design or security choices.