CVE-2026-62290: 
Wolfi vulnerability analysis and mitigation

CVE-2026-62290 is an Incorrect Authorization vulnerability in cert-manager (GHSA-8rvj-mm4h-c258) that allows authenticated Kubernetes namespace users to bypass DNS01 solver selectors and cause cert-manager to use ClusterIssuer DNS credentials for attacker-controlled provider settings and DNS names. The vulnerability affects cert-manager versions 1.18.0 through 1.19.5 and 1.20.0 through 1.20.2. It was disclosed on June 25, 2026, and has a CVSS v3.1 base score of 7.3 (High) (GitHub Advisory).

The root cause (CWE-863: Incorrect Authorization) lies in cert-manager performing no admission validation when a Challenge resource under acme.cert-manager.io is created directly by a namespace user — there is no check tying the Challenge to an Order, an owner reference, or an Issuer-selected solver. The ACME Challenge controller reconciles the directly-created resource and uses the attacker-controlled Challenge.spec.solver as the DNS01 provider configuration, while deriving the credential namespace and ambient-credential policy from the issuerRef (which can reference a ClusterIssuer). This allows an attacker to bypass Issuer/ClusterIssuer solver selectors (dnsZones, dnsNames, matchLabels) and, in the acme-dns case, cause cert-manager to send X-Api-User and X-Api-Key headers to an attacker-controlled endpoint. The default cert-manager-edit aggregate ClusterRole granted namespace users the create verb on challenges.acme.cert-manager.io, making this exploitable without any additional privilege escalation in default deployments (GitHub Advisory, PR #8940).

The primary impact is credential disclosure: a low-privileged namespace user can exfiltrate DNS provider API credentials (specifically X-Api-User and X-Api-Key headers for acme-dns) to an attacker-controlled endpoint, compromising confidentiality of platform-owned secrets. For other DNS01 providers, the impact includes unauthorized use of ClusterIssuer credentials, bypass of Issuer solver policy, and potential unauthorized DNS mutation — which could enable domain hijacking or certificate issuance for domains the attacker does not control. Availability is not directly impacted, and integrity impact is limited to low-level DNS record manipulation (GitHub Advisory).

A detailed proof-of-concept is publicly available in the official security advisory, including a complete bash script (PoC A) demonstrating credential disclosure via a crafted Challenge YAML resource in a k3s cluster, and a unit test (PoC B) confirming that acme-dns credentials are sent to the configured host. Exploitation requires only low privileges (namespace-level create permission on challenges.acme.cert-manager.io, which was granted by default via the cert-manager-edit aggregate ClusterRole), no user interaction, and local (cluster-internal) access. There is no evidence of in-the-wild exploitation at this time, and the vulnerability is not listed in the CISA KEV catalog. The EPSS score is approximately 0.078% (GitHub Advisory).

1. Reconnaissance: Confirm that the target Kubernetes cluster runs cert-manager 1.18.0–1.19.5 or 1.20.0–1.20.2, that a ClusterIssuer with a DNS01 acme-dns solver exists, and that your namespace user account has create permission on challenges.acme.cert-manager.io (granted by default via the cert-manager-edit aggregate ClusterRole).
2. Set up attacker-controlled endpoint: Deploy an HTTP server (e.g., using netcat, python -m http.server, or a public service like requestbin) to capture incoming HTTP headers at a URL such as https://attacker.example/acmedns.
3. Craft malicious Challenge resource: Create a YAML manifest for a Challenge resource that references the target ClusterIssuer in spec.issuerRef, sets spec.dnsName to a domain covered by the ClusterIssuer's credentials, and sets spec.solver.dns01.acmeDNS.host to the attacker-controlled endpoint while referencing the legitimate accountSecretRef (e.g., cluster-acmedns-account in the cert-manager namespace).
4. Submit the Challenge: Apply the crafted manifest as the low-privileged namespace user: kubectl --as=system:serviceaccount:tenant:bob -n tenant apply -f malicious-challenge.yaml.
5. Capture credentials: The cert-manager controller reconciles the Challenge, loads the acme-dns account JSON from the ClusterIssuer's namespace, and sends an HTTP POST to the attacker-controlled host with X-Api-User and X-Api-Key headers containing the victim's DNS provider credentials.
6. Abuse captured credentials: Use the exfiltrated API credentials to authenticate directly to the legitimate acme-dns service and manipulate DNS TXT records, potentially enabling unauthorized certificate issuance or domain takeover (GitHub Advisory).

• Kubernetes API Audit Logs: Audit log entries showing create operations on challenges.acme.cert-manager.io by non-cert-manager service accounts or namespace users, especially where spec.solver.dns01.acmeDNS.host differs from the ClusterIssuer's configured host.
• Network: Outbound HTTP POST requests from the cert-manager controller pod to unexpected external hosts on paths such as /update (the acme-dns update endpoint), particularly to IPs or domains not matching the legitimate acme-dns server configured in the ClusterIssuer.
• Kubernetes Resources: Presence of Challenge resources in namespaces that lack corresponding Order resources or cert-manager owner references; Challenge resources with spec.solver values that do not match any solver defined in the referenced Issuer or ClusterIssuer.
• cert-manager Controller Logs: Log entries indicating reconciliation of Challenge resources with solver configurations not derived from the Order controller flow; unexpected DNS01 provider interactions for domains or hosts not in the ClusterIssuer's solver selectors (GitHub Advisory).

Upgrade cert-manager to version 1.19.6 or 1.20.3 (or later), which remove the create verb for challenges.acme.cert-manager.io and the create, patch, update verbs for orders.acme.cert-manager.io from the cert-manager-edit aggregate ClusterRole (PR #8940, PR #8941). As an immediate workaround prior to upgrading, manually remove create permissions on challenges.acme.cert-manager.io from any roles or ClusterRoles bound to namespace users, and audit existing Challenge resources for suspicious solver configurations referencing unexpected hosts. If DNS provider credential compromise is suspected, rotate all DNS API credentials referenced by ClusterIssuers. Note that tooling or workflows that directly create Challenge or Order resources outside the normal cert-manager flow will need explicit permission grants after upgrading (GitHub Advisory).

The vulnerability was reported by researchers kamil-sawicki, robertprast, and EQSTLab, and was addressed by cert-manager maintainer Richard Wall (wallrj-cyberark) from CyberArk. The advisory explicitly notes this is not merely an RBAC misconfiguration, but a design flaw where the controller should not treat user-controlled Challenge.spec.solver as authoritative for a referenced ClusterIssuer. The fix was noted as a potentially breaking change for users with direct Challenge/Order creation workflows, and the cert-manager team recommended all users upgrade immediately (GitHub Advisory, PR #8940).