What is the CVSS score of CVE-2026-42876?

CVE-2026-42876 has a CVSS 3.1 base score of 4.9 (Medium). CVSS vector: CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N. EPSS exploitation probability: 0.0%.

Is there a patch available for CVE-2026-42876?

Yes, a patch is available for CVE-2026-42876. Update the affected software to the latest version immediately.

External Secrets Operator CVE-2026-42876

MEDIUM

Improper Authorization (CWE-285)

2026-05-08 https://github.com/external-secrets/external-secrets

GHSA-fq7h-9x26-6j22

Kubernetes Authentication Bypass

4.9

CVSS 3.1 · GitHub Advisory

Severity by source

GitHub Advisory PRIMARY

4.9 MEDIUM

AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N

Primary rating from GitHub Advisory · only source for this CVE.

CVSS VectorGitHub Advisory

CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N

Attack Vector

Network

Attack Complexity

High

Privileges Required

Low

User Interaction

None

Scope

Changed

Confidentiality

Low

Integrity

Low

Availability

None

Lifecycle Timeline

Source Code Evidence Fetched

May 08, 2026 - 18:01 vuln.today

Analysis Generated

May 08, 2026 - 18:01 vuln.today

CVE Published

May 08, 2026 - 17:24 nvd

MEDIUM 4.9

DescriptionGitHub Advisory

ExternalSecrets allows users to craft Service Account tokens for misconfigured Service Accounts in namespaces the users have access to.

Impact

A user who only has permission to create ExternalSecret resources can cause the operator to create a Secret that Kubernetes will automatically populate with a long-lived token for the sepcified service account. This effectively allows the user to impersonate any service account in the namespace without needing direct create permissions on TokenRequest or Secrets of that type.

The problem is mitigated in severity by the fact that the user must have pre-existing permissions already at almost the same level as the escalation later gives. The attacker cannot use this method to gain access to more information without other things also being misconfigured in the ESO installation.

Patches

Disallow this combination including the bootstrap token secret type.

Workarounds

Add admission control logic to prevent the use of Templates targeting undesired Types
Remove Service Account Token generation via kube-controller-manager flags
Restrict User RBAC on production clusters and sensitive namespaces

AnalysisAI

External Secrets Operator versions 0.1.0 through 2.4.0 allow authenticated users with ExternalSecret creation permissions to escalate privileges by crafting Service Account token templates that cause the operator to generate long-lived tokens for any service account in the namespace. An attacker can impersonate service accounts without requiring direct TokenRequest or Secret creation permissions, effectively bypassing RBAC controls. The attack requires the attacker already has ExternalSecret creation permissions and the cluster must have service account token generation enabled, limiting the practical scope to already-privileged users seeking lateral privilege expansion within a namespace.

Technical ContextAI

External Secrets Operator (ESO) is a Kubernetes controller that integrates external secret management systems with Kubernetes Secrets. The vulnerability exists in the ExternalSecret validation logic (externalsecret_validator.go). When a user creates an ExternalSecret resource with a template type of 'kubernetes.io/service-account-token' combined with either a ServiceAccountNameKey annotation or a TemplateFrom directive targeting annotations, the operator fails to validate and reject this privileged combination. Instead, it proceeds to create a Kubernetes Secret that Kubernetes automatically populates with a long-lived bearer token for the specified service account. This bypasses normal RBAC because the operator runs with elevated privileges and can create secrets and request tokens that the original user could not directly access. The root cause is insufficient input validation in the template specification processing, allowing users to leverage the operator's high privileges to generate tokens they otherwise lack permission to request. The fix adds explicit validation in validatePrivilegedTemplate() to reject service account token and bootstrap token template types when combined with dangerous annotations or templateFrom configurations.

RemediationAI

Upgrade External Secrets Operator to version 2.4.1 or later immediately. The patched version adds admission control validation that rejects ExternalSecret resources with SecretTypeServiceAccountToken or SecretTypeBootstrapToken templates combined with ServiceAccountNameKey annotations or TemplateFrom directives targeting annotations. If immediate upgrade is not possible, apply the following workarounds per vendor guidance: implement additional admission control logic (ValidatingWebhookConfiguration) to prevent use of Templates targeting dangerous secret types and annotations; disable Service Account Token generation on the kube-controller-manager by removing the '--service-account-signing-key' flag if token generation is not required; restrict RBAC permissions for ExternalSecret resource creation to only trusted roles (service account operators, cluster admins) and avoid granting ExternalSecret creation permissions to developers in namespaces containing highly privileged service accounts. Each workaround has trade-offs: custom admission control adds operational complexity and requires webhook availability; disabling token generation breaks legitimate token provisioning workflows; strict RBAC limits developer agility but is the most robust defense. Reference vendor patch at https://github.com/external-secrets/external-secrets/commit/4ddd240af7fe88725d9857b9a0c198073502e288 and release notes at https://github.com/external-secrets/external-secrets/releases/tag/v2.4.1.