GHSA-FQ7H-9X26-6J22
Vulnerability from github – Published: 2026-05-08 17:24 – Updated: 2026-05-08 17:24ExternalSecrets 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
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/external-secrets/external-secrets/apis"
},
"ranges": [
{
"events": [
{
"introduced": "0.1.0"
},
{
"fixed": "2.4.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-42876"
],
"database_specific": {
"cwe_ids": [],
"github_reviewed": true,
"github_reviewed_at": "2026-05-08T17:24:15Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "ExternalSecrets allows users to craft Service Account tokens for misconfigured Service Accounts in namespaces the users have access to.\n\n### Impact\n\nA 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.\n\nThe 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.\n\n### Patches\n\nDisallow this combination including the bootstrap token secret type.\n\n### Workarounds\n\n* Add admission control logic to prevent the use of Templates targeting undesired Types\n* Remove Service Account Token generation via kube-controller-manager flags\n* Restrict User RBAC on production clusters and sensitive namespaces",
"id": "GHSA-fq7h-9x26-6j22",
"modified": "2026-05-08T17:24:15Z",
"published": "2026-05-08T17:24:15Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/external-secrets/external-secrets/security/advisories/GHSA-fq7h-9x26-6j22"
},
{
"type": "WEB",
"url": "https://github.com/external-secrets/external-secrets/commit/4ddd240af7fe88725d9857b9a0c198073502e288"
},
{
"type": "PACKAGE",
"url": "https://github.com/external-secrets/external-secrets"
},
{
"type": "WEB",
"url": "https://github.com/external-secrets/external-secrets/releases/tag/v2.4.1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N",
"type": "CVSS_V3"
}
],
"summary": "ExternalSecrets vulnerable to privilege escalation with secret overwriting"
}
Sightings
| Author | Source | Type | Date | Other |
|---|
Nomenclature
- Seen: The vulnerability was mentioned, discussed, or observed by the user.
- Confirmed: The vulnerability has been validated from an analyst's perspective.
- Published Proof of Concept: A public proof of concept is available for this vulnerability.
- Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
- Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
- Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
- Not confirmed: The user expressed doubt about the validity of the vulnerability.
- Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.