cert-manager CVE-2026-62290

Exploitation requires an authenticated Kubernetes principal (PR:L) that already holds the 'create' verb on acme.cert-manager.io Challenge (and/or Order) resources in a namespace - the permission granted by cert-manager's default pre-fix Helm RBAC. The cluster must define at least one ClusterIssuer using a DNS01 solver whose credentials are worth stealing (e.g. acme-dns with X-Api-User/X-Api-Key). The core enabling condition is the absence of admission validation binding a user-created Challenge to an Order, owner reference, or Issuer-selected solver, which lets attacker-controlled Challenge.spec.solver values reference a ClusterIssuer and bypass dnsZones/dnsNames/matchLabels selectors. Limiting factors: single-tenant clusters, clusters using only namespaced Issuers, or clusters that already restrict Challenge/Order create rights are not exploitable; no code execution is gained (impact is credential/scope confidentiality), and the attacker must possess valid cluster credentials - this is not remotely reachable by an anonymous outsider.

The vendor CVSS 3.1 vector (AV:L/AC:L/PR:L/UI:N/S:C/C:H/I:L/A:N, base 7.3) reflects a low-complexity attack by an already-authenticated, low-privileged namespace tenant with a scope change (the vulnerable namespaced component reaches cluster-scoped ClusterIssuer credentials) and high confidentiality impact. This is a genuine multi-tenant isolation break rather than an inflated high-CVSS finding: the impact - theft of shared DNS provider credentials - is concrete and enables downstream DNS control. However, real-world risk is bounded by prerequisites: the cluster must be multi-tenant, must use a ClusterIssuer with a DNS01 solver holding valuable credentials, and the attacker must already possess namespace create rights on ACME resources. No EPSS score, KEV entry, or POC was provided, so exploitation appears theoretical/targeted rather than widespread; absence of these signals is consistent with a config-and-tenancy-dependent flaw. One note of caution: the vendor uses AV:L, but the Kubernetes API server is network-reachable, so an argument for AV:N (network-facing API) exists - this is a defensible modeling difference, not a contradiction with the description.

A tenant confined to their own namespace but granted the default cert-manager RBAC crafts a Challenge resource whose spec.solver references a cluster-wide DNS01 ClusterIssuer and specifies attacker-chosen DNS names and provider settings. cert-manager processes the forged Challenge using the ClusterIssuer's DNS credentials, and the tenant observes the resulting solver behavior and leaked provider headers (such as acme-dns X-Api-User and X-Api-Key), obtaining credentials that belong to the cluster rather than their namespace. No public exploit code was identified, but the attack requires only routine Kubernetes API calls with existing tenant permissions.