CVE-2024-45041
📋 TL;DR
External Secrets Operator versions before 0.10.2 have an overly permissive ClusterRole that allows the default-external-secrets-cert-controller deployment to read all secrets in the Kubernetes cluster and manipulate validating webhook configurations. This affects any Kubernetes cluster running vulnerable versions of External Secrets Operator, potentially exposing all cluster secrets and allowing denial of service attacks.
💻 Affected Systems
- External Secrets Operator
📦 What is this software?
External Secrets Operator by External Secrets
⚠️ Risk & Real-World Impact
Worst Case
An attacker with access to the service account token could exfiltrate all secrets in the cluster (including credentials, certificates, and sensitive data) and create a webhook that denies all Pod creation/update requests, causing complete cluster disruption.
Likely Case
Privilege escalation allowing unauthorized access to sensitive secrets stored in the cluster, potentially leading to credential theft and lateral movement.
If Mitigated
Limited impact if proper network policies, RBAC auditing, and service account token restrictions are in place to prevent token exfiltration.
🎯 Exploit Status
Exploitation requires access to the service account token, which can be obtained through pod compromise, misconfigured RBAC, or other initial access vectors.
🛠️ Fix & Mitigation
✅ Official Fix
Patch Version: 0.10.2
Vendor Advisory: https://github.com/external-secrets/external-secrets/security/advisories/GHSA-qwgc-rr35-h4x9
Restart Required: Yes
Instructions:
1. Update External Secrets Operator to version 0.10.2 or later using your deployment method (Helm, kubectl, etc.). 2. Verify the cert-controller deployment is using the updated ClusterRole with reduced permissions. 3. Restart affected pods to apply changes.
🔧 Temporary Workarounds
Manually restrict ClusterRole permissions
allModify the default-external-secrets-cert-controller ClusterRole to remove excessive permissions before patching.
kubectl edit clusterrole default-external-secrets-cert-controller
Disable cert-controller if not needed
allIf certificate management via the cert-controller is not required, scale the deployment to zero.
kubectl scale deployment default-external-secrets-cert-controller --replicas=0 -n external-secrets
🧯 If You Can't Patch
- Implement network policies to restrict pod-to-API-server communication
- Enable and monitor Kubernetes audit logs for suspicious secret access patterns
🔍 How to Verify
Check if Vulnerable:
Check if the cert-controller ClusterRole has 'get,list' verbs on secrets resources: kubectl describe clusterrole default-external-secrets-cert-controller | grep -A5 'secrets'Check Version:
kubectl get deployment -n external-secrets -o jsonpath='{.items[*].spec.template.spec.containers[*].image}' | grep -o 'external-secrets:[0-9.]*'Verify Fix Applied:
Verify the ClusterRole no longer has 'get,list' verbs on secrets and only has necessary permissions: kubectl describe clusterrole default-external-secrets-cert-controller📡 Detection & Monitoring
Log Indicators:
- Unusual secret access patterns from the cert-controller service account
- Modifications to validatingwebhookconfigurations by unauthorized users
Network Indicators:
- API server requests for secrets from the cert-controller pod outside normal patterns
SIEM Query:
kubernetes.audit.verb:(get|list) AND kubernetes.audit.resource:secrets AND kubernetes.audit.user.username:system:serviceaccount:external-secrets:default-external-secrets-cert-controller