Certighost (CVE-2026-54121): A Public Exploit Now Exists for This AD CS Domain Controller Impersonation Flaw

A public proof-of-concept exploit is now available for CVE-2026-54121, nicknamed “Certighost,” a critical Active Directory Certificate Services vulnerability that lets any authenticated, low-privileged domain user impersonate a Domain Controller. Microsoft patched it back in July 2026, but the release of a working public PoC changes the calculus significantly: any AD CS environment still unpatched is now a realistic, low-effort target rather than a theoretical risk. If you manage a Certificate Authority integrated with Active Directory and haven’t specifically confirmed this patch is applied, treat that as urgent.

What Certighost actually exploits

AD CS supports a certificate enrollment fallback mechanism, sometimes referred to as a “chase,” used during certain cross-domain-controller enrollment scenarios. This mechanism performs a second directory lookup to resolve identity information. The vulnerability lets an attacker manipulate specific request attributes (the client DC and remote domain fields in the enrollment request) to trick the Certificate Authority into querying an attacker-controlled host for identity information instead of a legitimate domain controller.

The practical result: a standard, unprivileged domain user account, with no administrative rights and no user interaction required from anyone else, can obtain a certificate that authenticates as a Domain Controller. That certificate can then be used to authenticate via Kerberos as if the attacker’s machine were a genuine DC, opening the door to a DCSync attack, extracting every password hash in the domain, including the krbtgt account’s hash.

Why this is more urgent now than when it was originally patched

A vulnerability with a patch available but no public exploit code is a real risk, but one many organizations reasonably deprioritize behind more actively-exploited issues. A public, working proof-of-concept exploit removes that reasoning. Once exploit code is publicly available, the skill and effort required to actually use it against an unpatched environment drops dramatically, and opportunistic scanning for vulnerable AD CS deployments becomes a realistic near-term threat rather than a hypothetical one. If Certighost slipped through your July 2026 patch cycle, whether due to a missed server, a delayed maintenance window, or simply not tracking every CVE from that month closely, this is worth specifically verifying now.

Confirming your exposure and patch status

# Identify all Enterprise Certification Authorities in your forest
Get-ADObject -Filter 'objectClass -eq "pKIEnrollmentService"' -SearchBase (Get-ADRootDSE).ConfigurationNamingContext -Properties dNSHostName |
    Select-Object Name, dNSHostName

# On each CA server, confirm the July 14, 2026 security update is installed
Get-HotFix | Where-Object { $_.InstalledOn -ge (Get-Date "2026-07-14") -and $_.InstalledOn -le (Get-Date "2026-07-21") } |
    Select-Object HotFixID, InstalledOn

Cross-reference the specific KB tied to CVE-2026-54121 in Microsoft’s Security Update Guide entry for that CVE against each CA server’s installed update history directly, rather than assuming a general “we patched in July” belief covers this specific fix.

Detection while you confirm and patch

Microsoft Defender for Identity includes a specific detection for this technique, surfaced as the alert “Potential Certighost (CVE-2026-54121) AD CS abuse.” If you run Defender for Identity, confirm this detection is enabled and review your alert history for any prior triggers you may not have investigated at the time. If you don’t run Defender for Identity, review AD CS enrollment logs directly for enrollment requests with anomalous client DC or remote domain attribute values, though this is considerably harder to do reliably without dedicated identity threat detection tooling.

What to do if you find evidence of exploitation

If you find indicators that this technique was used against your environment before patching, treat it the same way you would any confirmed Domain Controller impersonation: assume credential material, potentially including the krbtgt hash, may have been extracted, and follow the same response used for a confirmed DCSync event. That includes resetting the krbtgt password twice (a single reset does not fully invalidate tickets that may already have been forged using compromised credentials), reviewing for new or modified privileged group memberships, and preserving relevant logs before remediating, in case a fuller forensic review becomes necessary.

Frequently asked questions

Does this affect every AD CS deployment, or only specific configurations?
It specifically affects the cross-domain-controller enrollment fallback mechanism, meaning environments using standard, single-domain certificate enrollment without that fallback scenario are less directly exposed, but Microsoft’s guidance is to apply the patch to every server running an Enterprise Certification Authority regardless, since confirming your exact enrollment configuration doesn’t trigger the vulnerable path is harder to verify reliably than simply patching.

Is disabling AD CS entirely a reasonable short-term mitigation if I can’t patch immediately?
Only if your environment doesn’t depend on certificate-based authentication or encryption for anything currently in production, which is uncommon in any environment mature enough to have deployed AD CS in the first place. For most organizations, prioritizing an emergency patch window for CA servers specifically is more practical than disabling a service other systems likely depend on.

How do I know if the July 2026 patch on my CA servers is actually effective, not just installed?
Beyond confirming the KB is installed via Get-HotFix, monitor for the Defender for Identity Certighost-specific alert over a meaningful period after patching and treat a clean detection history as expected behavior, not proof by itself, since absence of an alert only means no exploitation attempt has been detected, not that the patch was necessarily applied correctly. Cross-referencing the installed KB against Microsoft’s official list for CVE-2026-54121 remains the authoritative check.