CVE-2025-66623
BaseFortify
Publication date: 2025-12-05
Last updated on: 2026-03-04
Assigner: GitHub, Inc.
Description
Description
CVSS Scores
EPSS Scores
| Probability: | |
| Percentile: |
Meta Information
Affected Vendors & Products
| Vendor | Product | Version / Range |
|---|---|---|
| linuxfoundation | strimzi | to 0.49.1 (exc) |
Helpful Resources
Exploitability
| CWE ID | Description |
|---|---|
| CWE-200 | The product exposes sensitive information to an actor that is not explicitly authorized to have access to that information. |
| CWE-863 | The product performs an authorization check when an actor attempts to access a resource or perform an action, but it does not correctly perform the check. |
Attack-Flow Graph
AI Powered Q&A
Can you explain this vulnerability to me?
This vulnerability occurs in Strimzi versions 0.47.0 up to but not including 0.49.1, where Strimzi incorrectly creates a Kubernetes Role that grants Apache Kafka Connect and Apache Kafka MirrorMaker 2 operands GET access to all Kubernetes Secrets in the namespace. This means these components can read all secrets in the Kubernetes namespace, which is more access than intended. The issue is fixed in Strimzi version 0.49.1.
How can this vulnerability impact me? :
The vulnerability can lead to unauthorized disclosure of sensitive information stored in Kubernetes Secrets within the affected namespace. Since Apache Kafka Connect and MirrorMaker 2 can access all secrets, an attacker or compromised component could retrieve confidential data such as credentials, tokens, or keys, potentially leading to data breaches or further system compromise.
What immediate steps should I take to mitigate this vulnerability?
Upgrade Strimzi to version 0.49.1 or later, as this version contains the fix for the incorrect Kubernetes Role creation that grants excessive GET access to Kubernetes Secrets.
How does this vulnerability affect compliance with common standards and regulations (like GDPR, HIPAA)?:
This vulnerability allows unauthorized GET access to all Kubernetes Secrets within a namespace by Kafka Connect and MirrorMaker 2 operands, potentially exposing sensitive information. Such exposure of confidential data can lead to non-compliance with data protection regulations like GDPR and HIPAA, which require strict controls on access to sensitive information. Therefore, the vulnerability poses a risk to compliance by enabling unauthorized disclosure of secrets that may contain personal or protected health information. [1]
How can this vulnerability be detected on my network or system? Can you suggest some commands?
To detect this vulnerability, you should check if your Strimzi Kafka Operator version is between 0.47.0 and 0.49.0 inclusive, and verify if the Kafka Connect or Kafka MirrorMaker 2 operands have Kubernetes Roles granting GET access to all Secrets in the namespace without proper TLS or mTLS authentication configured. You can inspect the Roles and RoleBindings in the affected namespace to see if they grant GET permissions on all Secrets. For example, use the following kubectl commands: 1. List Roles with GET access to secrets: kubectl get roles -n <namespace> -o json | jq '.items[] | select(.rules[]?.resources[]? == "secrets" and .rules[]?.verbs[]? == "get")' 2. Check RoleBindings associated with Kafka Connect or MirrorMaker 2 service accounts: kubectl get rolebindings -n <namespace> -o json | jq '.items[] | select(.subjects[]?.name | test("kafka-connect|kafka-mirrormaker2"))' 3. Verify the Kafka Connect and MirrorMaker 2 Custom Resources for TLS or mTLS configurations: kubectl get kafkaconnect <name> -n <namespace> -o yaml kubectl get kafkamirrormaker2 <name> -n <namespace> -o yaml Look for the presence of .spec.tls.trustedCertificates, .spec.authentication with type tls, or .spec.authentication.tlsTrustedCertificates fields. Absence of these indicates vulnerability. Note: jq is used here for JSON parsing; you can install it if not present. [1]