Description

External Secrets Operator reads information from a third-party service and automatically injects the values as Kubernetes Secrets. Starting in version 0.10.0 and prior to version 1.3.2, 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`. Version 1.3.2 contains a patch.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "7.1",
  "pubDate": "2026-10-06T16:17:07.180Z",
  "pubdate": "2026-10-06T16:17:07.180Z",
  "executiveSummary": "External Secrets Operator is susceptible to an authorization bypass vulnerability affecting its webhook generator component. The flaw originates from an improper initialization sequence that inadvertently resets the EnforceLabels flag.\nThis vulnerability allows an attacker to bypass critical security controls that mandate specific labeling for webhook secrets. By failing to validate the presence of the 'external-secrets.io/type=webhook' label, the operator incorrectly processes secrets that should have been rejected.\nThe vulnerability affects External Secrets Operator versions 0.10.0 through 1.3.1. The impact includes the potential unauthorized usage of improperly labeled secrets, which could lead to unintended integrations or data access. An attacker with the capability to create or modify Kubernetes Secrets within the cluster can exploit this oversight to circumvent administrative security policies. Successful exploitation does not require advanced external network access, as the flaw resides in the internal logic of the operator's controller and generator initialization process. Remediation requires upgrading to version 1.3.2 to ensure the enforcement logic remains persistent throughout the controller lifecycle.",
  "technicalDetails": "The vulnerability resides within the External Secrets Operator webhook generator initialization logic. In the affected versions (0.10.0 to 1.3.1), a logic error during the startup or reconciliation sequence causes the 'EnforceLabels' configuration flag to be overwritten or reset to a disabled state after it has been initially set.\nThe primary security control intended to mitigate risks associated with webhook-based secret injection is the enforcement of the 'external-secrets.io/type=webhook' label. This label serves as a gatekeeping mechanism to ensure that only authorized and explicitly flagged Kubernetes Secrets are processed by the webhook provider. When correctly functioning, the operator performs a provider-side check to verify the existence of this label before proceeding with the secret retrieval operation. If the label is missing, the operator is designed to abort the process and return an error: 'secret does not contain needed label 'external-secrets.io/type: webhook'.'\nThe exploitation flow involves a race condition or a state initialization failure where the 'EnforceLabels' flag is cleared prematurely. An attacker who has sufficient privileges to create a Kubernetes Secret within the namespace managed by the External Secrets Operator can define a Secret resource without the required 'external-secrets.io/type=webhook' label. Due to the faulty initialization logic, the webhook generator fails to validate the metadata of the secret against the required enforcement criteria. Consequently, the operator proceeds to process the payload as if it were a legitimate webhook-type secret.\nThis bypass effectively renders the security enforcement policy inert. The component responsible for the failure is the webhook generator initialization routine. Since the bug exists at the controller level, it affects any operation handled by the webhook generator where label enforcement was intended. There is no specific authentication requirement beyond the ability to interact with the Kubernetes API to create or patch secret resources. Once the generator is in the vulnerable state, any secret processed by the generator will bypass the label check, regardless of the attacker's namespace permissions. The post-exploitation impact allows for the unauthorized triggering of webhook operations, which may lead to secondary security implications depending on the downstream services configured for the webhook provider."
}