📄 Description (English)
External Secrets Operator reads information from a third-party service and automatically injects the values as Kubernetes Secrets. Starting in version 0.20.2 and prior to version 1.2.0, the `getSecretKey` template function, while introduced for senhasegura Devops Secrets Management (DSM) provider, has the ability to fetch secrets cross-namespaces with the roleBinding of the external-secrets controller, bypassing our security mechanisms. This function was completely removed in version 1.2.0, as everything done with that templating function can be done in a different way while respecting External Secrets Operator's safeguards As a workaround, use a policy engine such as Kubernetes, Kyverno, Kubewarden, or OPA to prevent the usage of `getSecretKey` in any ExternalSecret resource.
🤖 AI Executive Summary
External Secrets Operator versions 0.20.2 through 1.1.x contain a critical privilege escalation vulnerability in the getSecretKey template function that allows unauthorized cross-namespace secret access in Kubernetes environments. This vulnerability bypasses security mechanisms by leveraging the external-secrets controller's roleBinding permissions. The vulnerability has been completely removed in version 1.2.0, making immediate patching essential for organizations running affected versions.
📄 Description (Arabic)
🤖 AI Intelligence Analysis Analyzed: Apr 22, 2026 16:37
🇸🇦 Saudi Arabia Impact Assessment
This vulnerability poses significant risk to Saudi organizations utilizing Kubernetes-based infrastructure, particularly in: (1) Banking sector (SAMA-regulated institutions) managing sensitive financial data and customer credentials through containerized applications; (2) Government agencies (NCA oversight) running critical services on Kubernetes clusters; (3) Healthcare providers storing patient data and medical records; (4) Energy sector (ARAMCO and subsidiaries) managing operational technology secrets; (5) Telecommunications (STC, Mobily) handling subscriber information. The cross-namespace secret access capability could enable lateral movement and unauthorized access to sensitive credentials across multiple applications and environments within a single cluster.
🏢 Affected Saudi Sectors
Banking and Financial Services
Government and Public Administration
Healthcare and Medical Services
Energy and Utilities
Telecommunications
Critical Infrastructure
Cloud Service Providers
🎯 MITRE ATT&CK Techniques
⚖️ Saudi Risk Score (AI)
8.5
/ 10.0
🔧 Remediation Steps (English)
IMMEDIATE ACTIONS:
1. Identify all Kubernetes clusters running External Secrets Operator versions 0.20.2 through 1.1.x using: kubectl get deployment -A | grep external-secrets
2. Audit all ExternalSecret resources for usage of getSecretKey template function: kubectl get externalsecrets -A -o yaml | grep -i getsecretkey
3. Review RBAC bindings for external-secrets-controller service account to identify overly permissive roles
PATCHING GUIDANCE:
1. Upgrade External Secrets Operator to version 1.2.0 or later immediately
2. Test upgrade in non-production environment first
3. Verify all ExternalSecret resources function correctly post-upgrade
4. Monitor logs for any authentication failures during transition
COMPENSATING CONTROLS (if immediate patching not possible):
1. Implement Kubernetes Network Policies to restrict external-secrets controller communication
2. Deploy Kyverno or OPA policies to block any ExternalSecret resources containing getSecretKey function
3. Restrict RBAC permissions for external-secrets-controller to only required namespaces
4. Enable Kubernetes audit logging for all secret access attempts
5. Implement secret rotation policies for all credentials managed by External Secrets Operator
DETECTION RULES:
1. Monitor for ExternalSecret resources with getSecretKey in template specifications
2. Alert on cross-namespace secret access attempts by external-secrets-controller
3. Track RBAC role bindings changes for external-secrets service account
4. Log and alert on any failed secret access attempts across namespaces
🔧 خطوات المعالجة (العربية)
الإجراءات الفورية:
1. تحديد جميع مجموعات Kubernetes التي تشغل مشغل الأسرار الخارجية من الإصدارات 0.20.2 إلى 1.1.x باستخدام: kubectl get deployment -A | grep external-secrets
2. تدقيق جميع موارد ExternalSecret للتحقق من استخدام دالة getSecretKey: kubectl get externalsecrets -A -o yaml | grep -i getsecretkey
3. مراجعة ربط RBAC لحساب خدمة external-secrets-controller لتحديد الأدوار المفرطة في الأذونات
إرشادات التصحيح:
1. ترقية مشغل الأسرار الخارجية إلى الإصدار 1.2.0 أو أحدث فوراً
2. اختبار الترقية في بيئة غير الإنتاج أولاً
3. التحقق من أن جميع موارد ExternalSecret تعمل بشكل صحيح بعد الترقية
4. مراقبة السجلات لأي فشل في المصادقة أثناء الانتقال
الضوابط البديلة (إذا لم يكن التصحيح الفوري ممكناً):
1. تنفيذ سياسات شبكة Kubernetes لتقييد اتصالات متحكم الأسرار الخارجية
2. نشر سياسات Kyverno أو OPA لحظر أي موارد ExternalSecret تحتوي على دالة getSecretKey
3. تقييد أذونات RBAC لمتحكم external-secrets-controller إلى مساحات الأسماء المطلوبة فقط
4. تفعيل تسجيل تدقيق Kubernetes لجميع محاولات الوصول إلى الأسرار
5. تنفيذ سياسات تدوير الأسرار لجميع بيانات الاعتماد المدارة بواسطة مشغل الأسرار الخارجية
قواعد الكشف:
1. مراقبة موارد ExternalSecret التي تحتوي على getSecretKey في مواصفات القالب
2. تنبيه محاولات الوصول إلى الأسرار عبر مساحات الأسماء بواسطة external-secrets-controller
3. تتبع تغييرات ربط دور RBAC لحساب خدمة external-secrets
4. تسجيل والتنبيه على أي محاولات وصول فاشلة إلى الأسرار عبر مساحات الأسماء
📋 Regulatory Compliance Mapping
🟢 NCA ECC 2024
ECC 2024 A.5.1.1 - Access Control Policies
ECC 2024 A.5.2.1 - User Registration and De-registration
ECC 2024 A.5.3.1 - Access Rights Review
ECC 2024 A.8.2.1 - User Endpoint Devices
ECC 2024 A.8.3.1 - Information Access Restriction
🔵 SAMA CSF
SAMA CSF ID.AM-1 - Asset Management
SAMA CSF PR.AC-1 - Access Control
SAMA CSF PR.AC-3 - Access Enforcement
SAMA CSF PR.AC-4 - Access Rights Management
SAMA CSF DE.CM-1 - Detection and Analysis
🟡 ISO 27001:2022
ISO 27001:2022 A.5.2 - Information Security Policies
ISO 27001:2022 A.6.2 - Competence
ISO 27001:2022 A.8.1 - User Endpoint Devices
ISO 27001:2022 A.8.2 - Privileged Access Rights
ISO 27001:2022 A.8.3 - Information Access Restriction
ISO 27001:2022 A.9.2 - User Access Management
🟣 PCI DSS v4.0.1
PCI DSS 2.1 - Default Security Parameters
PCI DSS 6.2 - Security Patches
PCI DSS 7.1 - Limit Access to System Components
PCI DSS 8.2 - User Identification and Authentication
🔗 References & Sources 5
🔗
https://github.com/external-secrets/external-secrets/commit/17d3e22b8d3fbe339faf8515a95...
security-advisories@github.com
Patch
🔗
https://github.com/external-secrets/external-secrets/issues/5690
security-advisories@github.com
Issue Tracking
🔗
https://github.com/external-secrets/external-secrets/pull/3895
security-advisories@github.com
Issue Tracking
🔗
https://github.com/external-secrets/external-secrets/releases/tag/v1.2.0
security-advisories@github.com
Product
Release Notes
🔗
https://github.com/external-secrets/external-secrets/security/advisories/GHSA-77v3-r3jw...
security-advisories@github.com
Vendor Advisory
📦 Affected Products / CPE 1 entries
external-secrets:external_secrets_operator