CVE-2026-27133: Strimzi Kafka Operator Info Disclosure

CVE-2026-27133 Overview

CVE-2026-27133 is a Certificate Validation Bypass vulnerability affecting the Strimzi Kafka Operator, which provides a way to run Apache Kafka clusters on Kubernetes or OpenShift. From versions 0.47.0 to before 0.50.1, when a chain consisting of multiple CA (Certificate Authority) certificates is used in the trusted certificates configuration of a Kafka Connect operand or of the target cluster in the Kafka MirrorMaker 2 operand, all certificates in the CA chain are incorrectly trusted individually when connecting to Apache Kafka clusters.

Critical Impact

Affected Kafka Connect or Kafka MirrorMaker 2 operands may accept connections to Kafka brokers using server certificates signed by any CA in the chain, not just the intended terminal CA, potentially allowing unauthorized broker impersonation.

Affected Products

• Strimzi Kafka Operator versions 0.47.0 through 0.50.0
• Kafka Connect operands using CA certificate chains
• Kafka MirrorMaker 2 operands connecting to target clusters with CA chains

Discovery Timeline

• 2026-02-20 - CVE-2026-27133 published to NVD
• 2026-02-25 - Last updated in NVD database

Technical Details for CVE-2026-27133

Vulnerability Analysis

This vulnerability represents a Cryptographic Certificate Validation Bypass (CWE-295) that affects how Strimzi handles certificate authority chains in TLS configurations. When administrators configure trusted certificates for Kafka Connect or MirrorMaker 2 operands using a chain of multiple CA certificates, the operator incorrectly processes the chain, treating each certificate in the hierarchy as independently trusted rather than validating the complete chain relationship.

In a properly configured PKI environment, only the terminal CA (the last certificate in the chain) should be authorized to sign server certificates that are ultimately trusted. However, due to this flaw, intermediate CAs within the chain are also treated as valid signing authorities, expanding the trust boundary beyond what administrators intended.

The vulnerability requires high privileges to exploit, as an attacker would need the ability to obtain a certificate signed by one of the intermediate CAs in the chain. However, in enterprise environments where different organizational units control different intermediate CAs, this could allow cross-boundary trust violations.

Root Cause

The root cause lies in improper certificate chain validation logic within the Strimzi Kafka Operator. When processing CA certificate chains for TLS connections, the operator adds all certificates in the provided chain to the trust store individually, rather than properly validating that server certificates are signed specifically by the terminal CA. This implementation error causes the trust model to be more permissive than configured, as any CA certificate in the chain can effectively sign trusted server certificates.

Attack Vector

The attack vector is network-based and requires high privileges (typically access to an intermediate CA in the chain). An attacker with control over an intermediate CA certificate that appears in the trusted certificate chain could:

1. Generate a rogue server certificate signed by the intermediate CA
2. Deploy a malicious Kafka broker presenting this certificate
3. Intercept or redirect connections from affected Kafka Connect or MirrorMaker 2 operands
4. Potentially capture or manipulate data flowing through the connection

This attack scenario is primarily a concern in environments where multiple organizational units share a certificate chain hierarchy, as it could enable lateral movement or data interception between trust boundaries. The exploitation complexity is high because the attacker must possess or compromise an intermediate CA certificate already present in the target's trusted chain.

Detection Methods for CVE-2026-27133

Indicators of Compromise

• Unexpected TLS connections from Kafka Connect or MirrorMaker 2 pods to unrecognized Kafka broker endpoints
• Server certificates presented by Kafka brokers signed by intermediate CAs rather than the expected terminal CA
• Certificate chain validation logs showing trust decisions for intermediate CA-signed certificates
• Network traffic anomalies indicating connection redirects in Kafka communication paths

Detection Strategies

• Review TLS certificate configurations in all Kafka Connect and MirrorMaker 2 custom resources for multi-certificate CA chains
• Implement certificate transparency monitoring for certificates issued by any CA in your trusted chains
• Deploy network policy monitoring to detect connections to unexpected Kafka broker endpoints
• Audit Kubernetes events and operator logs for certificate-related warnings or errors

Monitoring Recommendations

• Enable verbose TLS logging on Strimzi operands to track certificate validation decisions
• Configure alerts for any Kafka Connect or MirrorMaker 2 connections to brokers not in the approved endpoint list
• Monitor for changes to spec.tls.trustedCertificates fields in Strimzi custom resources
• Implement periodic certificate chain audits comparing configured trust with operational requirements

How to Mitigate CVE-2026-27133

Immediate Actions Required

• Upgrade Strimzi Kafka Operator to version 0.50.1 or later immediately
• Review all Kafka Connect and MirrorMaker 2 operands using trustedCertificates configurations with CA chains
• Temporarily replace multi-certificate CA chains with single terminal CA certificates where possible
• Audit network policies to restrict Kafka broker connections to known-good endpoints

Patch Information

The Linux Foundation has addressed this vulnerability in Strimzi version 0.50.1. Organizations should upgrade to this version or later to remediate the certificate chain validation issue. The fix ensures that only the terminal CA in a certificate chain is trusted for validating server certificates.

For detailed patch information and upgrade instructions, see the Strimzi v0.50.1 Release and the GitHub Security Advisory.

Workarounds

• Configure trusted certificates using only the terminal CA certificate rather than the full chain
• Implement strict network policies limiting Kafka Connect and MirrorMaker 2 egress to known broker endpoints
• Use mutual TLS (mTLS) with client certificate validation to add an additional authentication layer
• Deploy a service mesh with certificate validation policies as an additional security control

# Verify Strimzi operator version
kubectl get deployment strimzi-cluster-operator -n kafka -o jsonpath='{.spec.template.spec.containers[0].image}'

# Review KafkaConnect resources with trustedCertificates
kubectl get kafkaconnects.kafka.strimzi.io -A -o jsonpath='{range .items[*]}{.metadata.name}{": "}{.spec.tls.trustedCertificates}{"\n"}{end}'

# Review KafkaMirrorMaker2 resources with trustedCertificates
kubectl get kafkamirrormaker2s.kafka.strimzi.io -A -o jsonpath='{range .items[*]}{.metadata.name}{": "}{.spec.clusters[*].tls.trustedCertificates}{"\n"}{end}'