Certighost (CVE-2026-54121): How Any Domain User Forges a Domain Controller Certificate

A domain user with no admin rights, ordinary network access to your certificate authority, and a default setting nobody reviews can walk away with a certificate that authenticates as one of your domain controllers. From there, DCSync pulls every account secret in the domain, including the krbtgt hash that signs every Kerberos ticket your forest issues. Microsoft's advisory calls this CVE-2026-54121. The two researchers who found it, H0j3n and Aniq Fakhrul, call it Certighost. Both names describe the same forged identity.

If you run Active Directory Certificate Services with an enterprise or standalone issuing CA that ordinary domain users can reach over the network, and that CA has not received Microsoft's July 2026 cumulative update, you are exposed right now. The requirement is a live CA role, not a specific product tier, and the attacker needs nothing beyond a standard domain account. If your organization has no on-prem AD CS at all, if certificate issuance runs through a cloud PKI service, or if your only issuing CA sits fully isolated from the user network with no direct LDAP or SMB path, this one does not reach you. Read the mechanism anyway; it is a template for how PKI trust boundaries fail more broadly, and it tells you what to ask an MSP or PKI vendor before you take their word that you are clear.

How the chase fallback turns a certificate request into a DC forgery

AD CS supports a legacy behavior called a chase: when a certificate authority cannot resolve the identity behind a request on its own, it can follow two attributes supplied inside that request, cdc (the client DC to contact) and rmd (the remote principal to look up), and go ask that named host who the requester really is. The intent was cross-domain enrollment convenience. The flaw is that the vulnerable CA code accepted the cdc value at face value and never confirmed the host it was talking to was an actual domain controller before trusting its answer.

The attack chain runs in five steps, documented in the researchers' public write-up and automated in their released tool. First, the attacker creates a computer account, something any authenticated user can do by default because ms-DS-MachineAccountQuota ships set to 10. Second, the attacker stands up rogue LSA and LDAP services on a host they control. Third, they submit a certificate request with cdc pointing at that rogue host and rmd naming the distinguished name of a real domain controller. Fourth, the vulnerable CA follows cdc, queries the attacker's fake LDAP service, and accepts the returned SID and DNS hostname as belonging to the DC named in rmd. Fifth, the CA issues a certificate carrying that domain controller's identity, which the attacker now uses to authenticate as a DC and run DCSync against the directory.

The disclosure timeline matters for anyone deciding how urgently to act. H0j3n and Aniq Fakhrul reported the underlying flaw to Microsoft on May 14, 2026. Microsoft confirmed it on May 22 and shipped a fix in the July 14 cumulative update, ten days ahead of the public write-up. The researchers published full technical detail and a working exploit tool on July 24. That sequence means every CA that took the July update before the 24th was already covered before the mechanism became public, and every CA still running June or earlier builds has been sitting exposed against a now-published tool for roughly a week.

What a mature PKI program already does to keep this from mattering

Enterprises that treat AD CS as a tier-0 asset, the same trust tier as domain controllers themselves, were already positioned to absorb this one without panic. Their issuing CAs sit on a restricted management VLAN reachable only from a small set of administrative hosts, so an ordinary user account has no network path to submit a crafted request in the first place. Certificate templates go through periodic access review with a tool like Certipy or PSPKIAudit, hunting specifically for enrollment rights granted too broadly and for templates that allow client-supplied subject names. CA audit logging runs continuously with alerting wired to a SIEM, not just local event logs nobody reads until an incident forces the question.

None of that is exotic tooling. It is discipline applied consistently to one high-value system, funded by a team large enough to own PKI as a named responsibility. The translation for an environment without that team is not to buy the same stack. It is to take the three practices that actually mattered here, network isolation, quota discipline, and periodic template review, and apply them by hand to the one or two CAs a smaller environment actually runs.

The version that costs nothing for a one-CA environment

You do not need a dedicated PKI analyst to close the exposure this week. Four actions, in priority order:

Immediate actions

• Apply the July 2026 cumulative update to every CA. Microsoft's patch adds a validation routine, _ValidateChaseTargetIsDC, that confirms the cdc host is a genuine domain controller with the SERVER_TRUST_ACCOUNT flag set before trusting anything it returns. This is the actual fix; everything else below is a bridge until it lands.
• If you cannot patch tonight, disable the chase fallback outright with certutil -setreg policy\EditFlags -EDITF_ENABLECHASECLIENTDC followed by Restart-Service CertSvc -Force. This breaks legitimate cross-domain enrollment if you rely on it, which most single-domain SMB environments do not. Treat it as a stopgap, not a fix; re-enabling the flag later reopens the hole.
• Set ms-DS-MachineAccountQuota to 0 unless a specific, documented process needs ordinary users to create computer accounts. This is the single setting that most environments have never touched since the domain was stood up, and it is step one of the attack chain regardless of the CA patch level.
• Run Certipy's find module against your CA to enumerate enrollment permissions and template misconfigurations while you are already in there. It is free, it is the same tool researchers use to find these gaps, and a one-CA environment can review its output in under an hour.

What to hunt for tonight if you cannot confirm the patch immediately

Certificate issuance from the CA logs to Security Event IDs 4886 (request received) and 4887 (certificate issued). Microsoft Defender for Identity also ships a dedicated alert, "Potential Certighost (CVE-2026-54121) AD CS abuse," for tenants with the sensor deployed against the CA, and it fires directly off the same chase-fallback pattern rather than a generic anomaly score, so it is worth confirming the sensor actually covers your CA host, not just your domain controllers, before you assume the alert has you covered. Neither of those detections requires a SIEM budget beyond what most environments already run; both are native to Windows Server and the Defender for Identity sensor you likely already deployed for other identity coverage.

# Confirm the current machine account quota (default is 10; set to 0 unless justified)
Get-ADObject -Identity (Get-ADDomain).DistinguishedName -Property ms-DS-MachineAccountQuota |
    Select-Object -ExpandProperty ms-DS-MachineAccountQuota

# Pull certificate request/issuance events from the CA host for the last 7 days
# and surface any request whose subject or SAN references a domain controller
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4886,4887; StartTime=(Get-Date).AddDays(-7)} |
    Where-Object { $_.Message -match 'Domain Controller|CN=NTDS' } |
    Select-Object TimeCreated, Id, @{Name='Requester'; Expression={$_.Properties[1].Value}}

A hit on that second query is not automatically an active compromise, some legitimate DC certificate renewals will legitimately match, but any requester in the output who is not a machine account tied to a real domain controller is worth a same-night phone call to whoever owns your CA.

Full technical detail on the vulnerable and patched code paths is in Microsoft's MSRC advisory, the CVE record with CWE-285 (improper authorization) and a CVSS 3.1 base score of 8.8 is on NVD, and the researchers' proof-of-concept tooling, which automates the account creation, rogue service, and certificate request steps described above, is published at github.com/aniqfakhrul/CVE-2026-54121.

Cut the machine account quota, then confirm the July update actually landed

Patch the CA first; the registry workaround is a bridge, not a destination. Then check the one setting that determines how many of your domain users could have started this chain in the first place. The quota sitting at 10 traces back to a Windows Server default from the original domain build. Almost nobody sets it deliberately, and almost nobody revisits it after that first install. Fixing it takes five minutes and closes the door on this technique and several others that depend on the same starting move.

We assess Active Directory Certificate Services deployments as part of our broader identity infrastructure reviews, specifically for exposed enrollment permissions, quota misconfigurations, and CA network placement, the three things a mature PKI program gets right and a single-admin environment usually has not had time to check.