EUVD-2026-45017Severity by source
AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N
Authenticated tenant (PR:L) reaches the network-facing Kubernetes API (AV:N/AC:L) and crosses tenancy scope (S:C) to disclose cluster DNS credentials (C:H), with limited integrity and no availability impact.
Primary rating from Vendor (GitHub_M).
CVSS VectorVendor: GitHub_M
Lifecycle Timeline
4DescriptionCVE.org
cert-manager adds certificates and certificate issuers as resource types in Kubernetes clusters, and simplifies the process of obtaining, renewing and using those certificates. From 1.18.0 until 1.19.6 and 1.20.3, Challenge resources under acme.cert-manager.io can be created directly by namespace users without admission validation tying the Challenge to an Order, owner reference, or Issuer-selected solver, allowing attacker-controlled Challenge.spec.solver values referencing a ClusterIssuer to bypass DNS01 solver selectors such as dnsZones, dnsNames, and matchLabels and cause cert-manager to use ClusterIssuer DNS credentials for attacker-selected provider settings and DNS names, including disclosure of X-Api-User and X-Api-Key headers for acme-dns. This issue is fixed in versions 1.19.6 and 1.20.3.
Articles & Coverage 1
AnalysisAI
Improper authorization in cert-manager 1.18.0 through 1.19.5 and 1.20.0-1.20.2 lets a namespaced tenant with standard Challenge/Order create rights forge ACME Challenge resources that reference a ClusterIssuer, bypassing DNS01 solver selectors (dnsZones, dnsNames, matchLabels) so the controller uses cluster-wide DNS credentials for attacker-chosen provider settings and names. The primary consequence is disclosure of shared ClusterIssuer DNS credentials - notably acme-dns X-Api-User and X-Api-Key headers - enabling cross-tenant credential theft in multi-tenant clusters. There is no public exploit identified at time of analysis, and it is not listed in CISA KEV.
Technical ContextAI
cert-manager is a Kubernetes controller that manages TLS certificate issuance via CRDs (Certificate, Issuer/ClusterIssuer, Order, Challenge) under groups cert-manager.io and acme.cert-manager.io. Normally a Challenge is created only by the cert-manager controller as a child of an Order, carrying an owner reference and a solver configuration selected by the Issuer/ClusterIssuer based on selector rules (dnsZones, dnsNames, matchLabels). The root cause is CWE-863 (Improper Authorization): the default RBAC shipped in the Helm chart granted end users the 'create' verb on challenges and orders, and there was no admission validation binding a user-created Challenge to a legitimate Order, owner reference, or Issuer-selected solver. This allowed a user to hand-craft Challenge.spec.solver, point it at a ClusterIssuer, and have the controller act with that ClusterIssuer's DNS provider credentials against arbitrary DNS names, defeating the selector-based scoping intended to isolate tenants. The upstream fix (PRs 8940/8941, commits 6bda472 and b37dbf0) removes the 'create' verb for challenges and 'create/patch/update' for orders from the user-facing RBAC role, while retaining patch/update/delete on challenges so users can still clear stuck finalizers.
RemediationAI
Vendor-released patch: upgrade to cert-manager 1.19.6 (https://github.com/cert-manager/cert-manager/releases/tag/v1.19.6) or 1.20.3 (https://github.com/cert-manager/cert-manager/releases/tag/v1.20.3), per advisory GHSA-8rvj-mm4h-c258. The fix ships in the Helm chart RBAC (PR 8940/8941) by removing the 'create' verb from user-facing roles for challenges and 'create/patch/update' for orders, so upgrading and re-applying the chart is the primary action. If you cannot upgrade immediately, apply the equivalent compensating control manually: edit your cert-manager RBAC (ClusterRoles/Roles bound to tenants) to drop 'create' on acme.cert-manager.io challenges and 'create/patch/update' on orders, retaining delete/patch/update on challenges only so tenants can still remove stuck finalizers - the trade-off is that any automation that legitimately creates Challenge/Order objects directly (uncommon, as the controller normally owns these) will break. Additionally, prefer namespaced Issuers over ClusterIssuers for tenant workloads, and scope/rotate the DNS provider credentials (including acme-dns X-Api-User/X-Api-Key) if you suspect prior exposure.
More in Kubernetes
View allA critical vulnerability in Kubernetes ingress-nginx controller allows unauthenticated attackers with pod network access
Credential-harvesting malware compromised 84 versions of 42 TanStack npm packages on 2026-05-11 via chained GitHub Actio
Kubernetes ingress-nginx contains a configuration injection vulnerability via the mirror-target and mirror-host Ingress
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-url` Ingres
A security issue was discovered in ingress-nginx https://github.com/kubernetes/ingress-nginx where the `auth-tls-match-c
Kubernetes API server in all versions allow an attacker who is able to create a ClusterIP service and set the spec.exter
A security issue was discovered in Kubernetes where a user that can create pods on Windows nodes may be able to escalate
Argo CD is a declarative, GitOps continuous delivery tool for Kubernetes. Rated critical severity (CVSS 9.9), this vulne
Unauthenticated remote attackers can trigger complete database overwrites, server-side file reads, and SSRF attacks agai
The Kubernetes integration in GitLab Enterprise Edition 11.x before 11.2.8, 11.3.x before 11.3.9, and 11.4.x before 11.4
Fluentd configuration injection in the kube-logging Logging operator before 6.6.0 allows a namespace-scoped user who can
Kyverno Kubernetes policy engine prior to 1.x has a privilege escalation vulnerability (CVSS 9.9) allowing policy bypass
Same weakness CWE-863 – Incorrect Authorization
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today