Strimzi allows unrestricted access to all Secrets in the same Kubernetes namespace from Kafka Connect and MirrorMaker 2 operands
Date: 2025-12
Affected: maven/io.strimzi:strimzi
Attack vector: other
Category: vulnerability-disclosure
Severity: High
CVE: CVE-2025-66623
CWE: CWE-200
CWE-863
CVSS: 7.4 (CVSS:3.1/AV:A/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N)

### Impact In some situations, Strimzi creates an incorrect Kubernetes `Role` which grants the Apache Kafka Connect and Apache Kafka MirrorMaker 2 operands the `GET` access to all Kubernetes Secrets that exist in the given Kubernetes namespace. The exact scenario when this happens is when: * Apache Kafka Connect is deployed without at least one of the following options configured: * TLS encryption with configured trusted certificates (no `.spec.tls.trustedCertificates` section in the `KafkaConnect` CR) * mTLS authentication (no `type: tls` in `.spec.authentication` section of the `KafkaConnect` CR) * TLS encryption with configured trusted certificates for `type: oauth` authentication (no `.spec.authentication.tlsTrustedCertificates` section in the `KafkaConnect` CR) * Apache Kafka MirrorMaker2 is deployed without at least one of the following options configured for the target cluster: * TLS encryption with configured trusted certificates (no `.spec.target.tls.trustedCertificates` section in the `KafkaConnect` CR) * mTLS authentication (no `type: tls` in `.spec.target.authentication` section of the `KafkaConnect` CR) * TLS encryption with configured trusted certificates for `type: oauth` authentication (no `.spec.target.authentication.tlsTrustedCertificates` section in the `KafkaConnect` CR) * TLS encryption with configured trusted certificates (no `.spec.clusters[].tls.trustedCertificates` section in the `KafkaConnect` CR for the target cluster)


Mitigations:

Architectural layers (MAESTRO):