CVE-2026-27134: Strimzi Kafka Operator Auth Bypass Flaw

CVE-2026-27134 Overview

CVE-2026-27134 is an authentication bypass vulnerability in Strimzi Kafka Operator versions 0.49.0 through 0.50.0, which provides a way to run Apache Kafka clusters on Kubernetes or OpenShift. 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 both internal and user-configured listeners. This misconfiguration causes all CAs from the CA chain to be trusted, allowing users with certificates signed by any of the CAs in the chain to authenticate—even those that should not be authorized.

Critical Impact

Unauthorized users with certificates signed by any CA in the chain can bypass mTLS authentication, potentially gaining access to Kafka clusters and sensitive data streams in Kubernetes/OpenShift environments.

Affected Products

• Linux Foundation Strimzi Kafka Operator versions 0.49.0 through 0.50.0
• Kubernetes deployments using custom Cluster CA with multistage CA chains
• OpenShift deployments using custom Clients CA with multistage CA chains

Discovery Timeline

• 2026-02-21 - CVE-2026-27134 published to NVD
• 2026-02-25 - Last updated in NVD database

Technical Details for CVE-2026-27134

Vulnerability Analysis

The vulnerability (CWE-287: Improper Authentication) stems from how Strimzi Kafka Operator handles certificate trust configuration when custom Certificate Authorities are deployed with multistage CA chains. In a properly configured mTLS environment, only specific CAs should be trusted for client authentication. However, when a multistage CA chain is provided as a custom Cluster or Clients CA, Strimzi incorrectly adds all intermediate and root CAs from the chain to the trust store used for mTLS authentication.

This means that if an organization's CA hierarchy includes multiple intermediate CAs, any certificate signed by any CA in that hierarchy—including CAs intended for other purposes or departments—would be accepted for Kafka authentication. This fundamentally breaks the intended access control model.

Root Cause

The root cause lies in the certificate trust configuration logic within the Strimzi Kafka Operator. When processing a custom CA chain, the operator fails to isolate the specific CA that should be trusted for client authentication. Instead, it recursively trusts all certificates in the provided chain, effectively expanding the trust boundary beyond what administrators intended. This behavior occurs because the code does not properly distinguish between CA certificates that should be used for chain validation versus those that should be explicitly trusted for authentication purposes.

Attack Vector

The attack vector is network-based, requiring no user interaction and no prior privileges on the target system. An attacker who possesses a valid certificate signed by any CA in the trusted chain—not necessarily the intended authentication CA—can establish an mTLS connection to Kafka listeners. This is particularly dangerous in enterprise environments where multiple intermediate CAs exist for different organizational purposes. An attacker with access to certificates from a different organizational unit or purpose could potentially authenticate to the Kafka cluster.

The vulnerability manifests in the mTLS handshake process where the Kafka broker validates client certificates. Instead of checking that the client certificate was signed by the specific designated CA, the broker accepts certificates signed by any CA present in the configured chain. For detailed technical information, refer to the GitHub Security Advisory GHSA-2qwx-rq6j-8r6j.

Detection Methods for CVE-2026-27134

Indicators of Compromise

• Unexpected authentication successes from certificates signed by CAs other than the designated authentication CA
• Kafka broker logs showing client connections with certificates from unexpected issuers
• Anomalous access patterns from services or users that should not have Kafka access
• Certificate chain validation logs indicating trust of intermediate CAs beyond the intended scope

Detection Strategies

• Review Kafka broker authentication logs for client certificates signed by unexpected CAs in the chain
• Audit current trust store configuration in Strimzi-managed Kafka clusters to identify overly permissive CA trust
• Implement certificate issuer monitoring to alert when connections originate from certificates signed by CAs outside the expected authentication CA
• Compare active client certificate issuers against the intended single CA that should be trusted

Monitoring Recommendations

• Enable detailed TLS handshake logging on Kafka listeners to capture certificate chain information
• Deploy certificate transparency monitoring for your organization's CA infrastructure
• Implement Kubernetes audit logging to track changes to Strimzi Kafka custom resources
• Monitor for unusual Kafka consumer/producer activity that may indicate unauthorized access

How to Mitigate CVE-2026-27134

Immediate Actions Required

• Upgrade Strimzi Kafka Operator to version 0.50.1 immediately if using custom CA chains
• Audit all Kafka clusters using custom Cluster or Clients CAs with multistage CA chains
• Review authentication logs for any evidence of unauthorized access prior to patching
• Consider rotating Kafka cluster credentials after upgrading as a precautionary measure

Patch Information

The vulnerability has been fixed in Strimzi Kafka Operator version 0.50.1. Organizations running affected versions (0.49.0 through 0.50.0) with custom multistage CA chains should upgrade immediately. The patch ensures that only the specifically designated CA is trusted for mTLS authentication, rather than all CAs in the provided chain. For release details, see the Strimzi 0.50.1 Release Notes.

Workarounds

• Provide only the single CA that should be used for authentication, rather than the full CA chain
• Remove intermediate and root CAs from the custom CA configuration, keeping only the leaf CA intended for client authentication
• If full CA chain is required for other purposes, consider switching to Strimzi-managed Cluster and Clients CAs temporarily until upgrade is possible
• Implement network-level access controls as an additional defense layer while awaiting the upgrade

# Configuration example - Provide only the single authentication CA
# Instead of providing the full chain:
# kubectl create secret generic my-cluster-ca --from-file=ca.crt=full-chain.pem

# Provide only the specific CA for authentication:
kubectl create secret generic my-cluster-ca --from-file=ca.crt=single-auth-ca.pem

# Verify the secret contains only the intended CA
kubectl get secret my-cluster-ca -o jsonpath='{.data.ca\.crt}' | base64 -d | openssl x509 -noout -subject -issuer