CVE-2026-27133
📋 TL;DR
This vulnerability in Strimzi allows Kafka Connect or Kafka MirrorMaker 2 operands to incorrectly trust all certificates in a CA chain when connecting to Kafka brokers, rather than only trusting the final CA. This could enable unauthorized connections using certificates signed by intermediate CAs. Organizations using Strimzi versions 0.47.0 through 0.50.0 with multi-CA certificate chains are affected.
💻 Affected Systems
- Strimzi Kafka Operator
📦 What is this software?
Strimzi by Linuxfoundation
⚠️ Risk & Real-World Impact
Worst Case
An attacker could impersonate legitimate Kafka brokers using certificates signed by intermediate CAs in the trusted chain, potentially intercepting or manipulating data streams between Kafka components.
Likely Case
Accidental misconfiguration could allow connections from unintended brokers, leading to data integrity issues or unauthorized data access within the Kafka ecosystem.
If Mitigated
With proper network segmentation and certificate management, the impact is limited to potential configuration errors rather than active exploitation.
🎯 Exploit Status
Exploitation requires access to create or modify certificates within the trusted CA chain and knowledge of the specific Strimzi configuration.
🛠️ Fix & Mitigation
✅ Official Fix
Patch Version: 0.50.1
Vendor Advisory: https://github.com/strimzi/strimzi-kafka-operator/security/advisories/GHSA-6x85-j2f7-4xc5
Restart Required: Yes
Instructions:
1. Update Strimzi operator to version 0.50.1 or later using your preferred deployment method (Helm, OperatorHub, YAML manifests). 2. Restart all Kafka Connect and Kafka MirrorMaker 2 pods to apply the fix. 3. Verify certificate validation is working correctly.
🔧 Temporary Workarounds
Simplify CA Certificate Chains
allUse single CA certificates instead of multi-CA chains in Kafka Connect and Kafka MirrorMaker 2 configurations
# Edit KafkaConnect or KafkaMirrorMaker2 CR to use single CA certificate
kubectl edit kafkaconnect <name> -n <namespace>
# Or for MirrorMaker2
kubectl edit kafkamirrormaker2 <name> -n <namespace>
🧯 If You Can't Patch
- Implement network policies to restrict Kafka Connect and MirrorMaker 2 pods to only communicate with authorized Kafka brokers
- Monitor and audit all certificate changes in your CA chains and alert on unexpected intermediate CA usage
🔍 How to Verify
Check if Vulnerable:
Check Strimzi operator version and verify if any KafkaConnect or KafkaMirrorMaker2 resources use multi-CA certificate chains in their trusted certificates configuration.Check Version:
kubectl get deployment strimzi-cluster-operator -o jsonpath='{.spec.template.spec.containers[0].image}' | grep -o ':[0-9.]*' | cut -d: -f2Verify Fix Applied:
After upgrading to 0.50.1+, test certificate validation by attempting to connect with certificates signed by intermediate CAs (should be rejected).📡 Detection & Monitoring
Log Indicators:
- Unexpected certificate validation successes in Kafka Connect or MirrorMaker 2 logs
- Connections from brokers with certificates signed by intermediate CAs
Network Indicators:
- Unusual network connections between Kafka components
- Traffic patterns suggesting broker impersonation
SIEM Query:
source="kafka-connect-logs" AND ("certificate validation" OR "CA chain") AND (success OR accepted)