CVE-2025-66623
📋 TL;DR
This vulnerability in Strimzi Kafka Operator versions 0.47.0 through 0.49.0 creates an overly permissive Kubernetes Role that grants Kafka Connect and Kafka MirrorMaker 2 pods GET access to all Secrets in their namespace. This allows unauthorized reading of sensitive Kubernetes Secrets. Organizations running affected Strimzi versions on Kubernetes/OpenShift are impacted.
💻 Affected Systems
- Strimzi Kafka Operator
📦 What is this software?
Strimzi by Linuxfoundation
⚠️ Risk & Real-World Impact
Worst Case
Attackers could exfiltrate all Kubernetes Secrets in the namespace, including database credentials, API keys, TLS certificates, and other sensitive data, potentially leading to complete cluster compromise.
Likely Case
Unauthorized access to sensitive configuration data stored in Kubernetes Secrets, enabling lateral movement and privilege escalation within the cluster.
If Mitigated
Limited exposure if proper network policies, RBAC restrictions, and namespace segregation are already implemented.
🎯 Exploit Status
Exploitation requires access to the Kubernetes cluster and ability to interact with the vulnerable pods. The misconfigured RBAC makes exploitation straightforward for authenticated attackers.
🛠️ Fix & Mitigation
✅ Official Fix
Patch Version: 0.49.1
Vendor Advisory: https://github.com/strimzi/strimzi-kafka-operator/security/advisories/GHSA-xrhh-hx36-485q
Restart Required: Yes
Instructions:
1. Upgrade Strimzi Kafka Operator to version 0.49.1 or later. 2. Update all Kafka Connect and Kafka MirrorMaker 2 deployments. 3. Verify the new RoleBindings restrict Secret access appropriately.
🔧 Temporary Workarounds
Manual RBAC Correction
allManually edit the Kubernetes Role to remove excessive Secret permissions
kubectl edit role <role-name> -n <namespace>
Remove the 'secrets' resource from the rules section
Network Policy Isolation
allRestrict network access to vulnerable pods to prevent exploitation
kubectl apply -f network-policy.yaml
🧯 If You Can't Patch
- Implement strict network policies to isolate Kafka Connect and MirrorMaker pods from other services
- Use Kubernetes Admission Controllers to audit and block excessive RBAC permissions
🔍 How to Verify
Check if Vulnerable:
Check if Strimzi version is between 0.47.0 and 0.49.0, and examine Role definitions for Kafka Connect/MirrorMaker 2 with 'kubectl get role -n <namespace>'Check Version:
kubectl get deployment strimzi-cluster-operator -o jsonpath='{.spec.template.spec.containers[0].image}'Verify Fix Applied:
Verify Strimzi version is 0.49.1+, and confirm Role no longer grants GET access to all Secrets with 'kubectl describe role <role-name> -n <namespace>'📡 Detection & Monitoring
Log Indicators:
- Unusual Secret access patterns from Kafka Connect/MirrorMaker pods
- Failed RBAC authorization attempts for Secret resources
Network Indicators:
- Unexpected outbound connections from Kafka pods to external systems
SIEM Query:
source="kubernetes" AND (resource.type="secrets" AND verb="get") AND user.agent="kafka-connect" OR user.agent="mirrormaker"