Strimzi (Kafka on Kubernetes) – mTLS Trust Bypass
CVE ID: CVE-2026-27134
Affected Product: Strimzi Kafka Operator
Affected Versions: 0.49.0 and 0.50.0
Fixed Version: 0.50.1 and later
CVSS v3.1 Score: 8.1 (High)
Severity: High
Attack Vector: Network
Privileges Required: None
User Interaction: None
Impact: Confidentiality, Integrity, Availability – High
This vulnerability exists in Strimzi when a custom Certificate Authority (CA) chain containing multiple CAs is supplied for mutual TLS (mTLS) authentication. During certificate validation, all CAs within the provided chain are treated as trusted authorities for client authentication.
As a result, a client certificate signed by any CA present in that chain is accepted, even if only one specific CA was intended to be trusted for user authentication.
This behavior effectively broadens the trust boundary and allows unintended certificate issuers to authenticate clients successfully.
Technical Root Cause
Strimzi allows administrators to configure custom CAs for:
- Cluster CA (broker authentication)
- Clients CA (client authentication)
When a multi-CA chain (e.g., Root CA → Intermediate CA → Another CA) is provided inside the trusted certificate bundle, the certificate validation logic does not restrict authentication to a specific CA within the chain. Instead, every CA certificate contained in that bundle becomes a trust anchor.
The expected behavior would restrict trust to the designated root or specified CA. The implemented behavior incorrectly trusts every CA certificate present in the provided chain.
This leads to improper certificate chain validation and authentication boundary expansion.
Conditions Required for Exploitation
The following must be true for exploitation:
- A custom CA is configured (Strimzi-managed CA not affected).
- The CA bundle contains multiple CA certificates.
- mTLS client authentication is enabled.
- An attacker possesses a client certificate signed by one of the CAs in the chain.
If these conditions are met, authentication bypass becomes possible.
Exploitation Scenario (Educational)
The vulnerability does not require a memory corruption exploit or binary payload. It is purely a trust misconfiguration issue.
A theoretical exploitation flow:
- A certificate is issued from an intermediate CA included in the trusted chain.
- The attacker configures a Kafka client using that certificate and private key.
- A TLS connection is initiated to the Kafka listener requiring mTLS.
- The broker validates the certificate chain.
- Because all CAs in the chain are treated as trusted roots, authentication succeeds.
Once authenticated, the attacker operates as a valid Kafka principal.
Client Usage (Educational)
kafka-console-producer.sh \
--broker-list broker:9093 \
--topic sensitive-topic \
--producer.config client.properties
client.properties:
security.protocol=SSL
ssl.keystore.location=attacker.p12
ssl.keystore.password=password
ssl.truststore.location=ca-chain.p12
ssl.truststore.password=password
If the certificate issuer matches any CA in the chain, authentication succeeds.
Potential Impact
Confidentiality Impact
Unauthorized clients may consume sensitive topics.
Integrity Impact
Messages may be injected, altered, or replayed.
Availability Impact
High-volume producers or consumer group abuse may degrade cluster performance.
Privilege Escalation Risk
If internal listeners share trust configuration, replication or system identities could potentially be impersonated in poorly segmented environments.
MITRE ATT&CK Mapping
- T1078 – Valid Accounts
- T1190 – Exploit Public-Facing Application
- T1552 – Unsecured Credentials
- T1550 – Use of Authentication Material
Exploit Availability
No publicly released weaponized exploit has been widely observed.
Because exploitation only requires possession of a certificate signed by a CA in the chain, proof-of-concept validation is straightforward in controlled lab environments.
No automated exploit kit is known at this time.
Detection Strategy
Detection should focus on:
- Unexpected certificate issuers
- New principals authenticating
- Unusual listener usage
- CA Secret modifications in Kubernetes
- Spikes in authentication success from new identities
Log Sources to Monitor
- Kafka broker
server.log - Strimzi operator pod logs
- Kubernetes audit logs
- Kubernetes Secret change events
- Load balancer / Ingress TLS logs
- SIEM ingestion of TLS metadata
Detection Rules
Splunk – Detect Unexpected Certificate Issuers
index=kafka_logs sourcetype=kafka_server
("SSL client authentication succeeded" OR "Principal =")
| rex "issuer=CN=(?<issuer_cn>[^,]+)"
| stats count by issuer_cn, principal, src_ip
| where issuer_cn!="ExpectedRootCA"
Splunk – Detect New Principals
index=kafka_logs sourcetype=kafka_server "Principal ="
| stats earliest(_time) as first_seen by principal
| where first_seen > relative_time(now(), "-24h")
ELK – Detect CA Secret Modification
event.dataset:kubernetes.audit
and kubernetes.resource.name:*ca*
and (verb:update OR verb:patch OR verb:replace)
ELK – Detect High Volume Auth Success
message:"SSL client authentication succeeded"
| stats count by client_ip
| where count > 100
Kubernetes Audit – Detect Kafka CR Changes
event.dataset:kubernetes.audit
and kubernetes.resource.kind:Kafka
and verb:update
Indicators of Suspicious Activity
- Client certificate issuer not matching intended root CA
- Sudden appearance of new Distinguished Names (DN)
- Internal listener accessed from unexpected IP ranges
- Kafka ACL denials disappearing unexpectedly
- CA Secret recently modified before unusual connections
Forensic Artifacts to Collect
- Broker logs showing authentication events
- Operator logs around CA loading
- Kubernetes Secret YAML revisions
- TLS handshake captures
- List of active consumer groups
- Topic access logs
- ACL configuration at time of incident
Remediation
Immediate Action
Upgrade Strimzi to 0.50.1 or later.
Official Patch / Upgrade Link:
https://github.com/strimzi/strimzi-kafka-operator/releases/tag/0.50.1
Temporary Workaround (If Upgrade Delayed)
- Do not include full CA chains in trusted certificate bundles.
- Include only the exact single CA certificate intended for authentication.
- Restrict internal listeners using network policies.
- Review and harden Kafka ACLs.
Post-Upgrade Validation Checklist
- Confirm Strimzi version ≥ 0.50.1.
- Verify only intended CA certificate is trusted.
- Validate authentication behavior with test certificates.
- Review broker logs for unknown principals.
- Rotate CA certificates if compromise suspected.
Risk Summary
This vulnerability represents an authentication trust expansion flaw rather than a memory corruption or remote code execution issue. However, because it affects identity verification at the TLS layer, the impact is significant in production Kafka environments handling sensitive data.
If custom multi-CA chains were used, immediate validation and upgrade should be prioritized.
