CVE-2026-54121: any AD user can now seize your domain

Any domain user, no admin rights, full domain compromise

CVE-2026-54121 — nicknamed "Certighost" by the researchers who reported it — is an improper-authorization flaw in Active Directory Certificate Services (AD CS) that lets any authenticated, low-privileged domain user impersonate a Domain Controller and walk out with the keys to the entire domain. No administrator rights, no user interaction, no social engineering. Just a valid domain account and network line-of-sight to an Enterprise Certification Authority. Microsoft patched it in the July 2026 security updates, and a working proof-of-concept was published on 24 July 2026 — which means every unpatched AD CS deployment is now a live target, not a theoretical one.

For a casino, exchange, or bank running on-premises Active Directory — which is most of them, even the ones that are otherwise cloud-first — this is as bad as AD bugs get. Whoever controls the domain controls every workstation, every file share, every service account, and every downstream system that trusts a Kerberos ticket. An attacker doesn't need to breach a perimeter twice. They need one intern's laptop and an unpatched CA.

What we know about CVE-2026-54121

• Vulnerability class: improper authorization in AD CS's directory-object resolution during certificate enrollment — the CA can be tricked into fetching identity data for a Domain Controller from an attacker-controlled host, then issuing a certificate based on that spoofed data.
• CVSS: 8.8, per Microsoft's own classification.
• Privileges required: a standard domain user account. No admin rights, no elevated group membership, no interaction from a victim.
• Impact: the attacker obtains a certificate that lets them authenticate as a Domain Controller. Because DC accounts hold directory replication rights, that credential can be used to run a DCSync-style pull of the domain's password hashes — including the krbtgt account, which is the master key for forging Kerberos tickets across the whole domain.
• Affected surface: any Enterprise Certification Authority running AD CS that has not applied Microsoft's July 2026 cumulative update.
• Patch status: fixed in the July 2026 security updates via a new validation step (_ValidateChaseTargetIsDC) that confirms a chase target is a genuine Domain Controller computer object before the CA trusts its identity data.
• Exploit availability: a public proof-of-concept was released 24 July 2026, roughly a day after the technical write-up. Treat every hour since then as exposure time for unpatched CAs.

We are not walking through the enrollment chase mechanics or publishing exploitation steps here. The PoC is already public if you need it for authorized testing; what matters for defense is the checklist below, and none of it requires understanding the exploit chain.

What to do in the next 24 hours

1. Patch every Enterprise CA to the July 2026 update, today. This is not a "next patch cycle" item — a public PoC against an 8.8 that ends in domain compromise is a stop-what-you're-doing patch. Inventory every AD CS role holder first; CAs stood up years ago for one project and forgotten are exactly where this bites.
2. Assume domain-account compromise is enough to test for this. Unlike most privilege-escalation bugs, the barrier to entry here is "any employee's credentials," which phishing, credential stuffing, or a stale password already gets an attacker. Don't gate your urgency on "do we think someone has admin" — assume the low bar is already met somewhere in your estate.
3. Audit for signs of DCSync activity. Review directory-service replication logs (Event ID 4662 with the replication-related GUIDs) for replication requests from hosts that are not your actual Domain Controllers. If you find one, treat the domain as compromised and rotate the krbtgt account twice, per Microsoft's standard golden-ticket recovery procedure — not once.
4. Tier your admin access if you haven't already. Certighost is a reminder that AD CS is a Tier 0 asset: anything that can mint a certificate trusted as a Domain Controller belongs in the same protection tier as the DCs themselves — restricted management workstations, no standing high-privilege sessions, no shared service accounts with enrollment rights they don't need.

If step 3 turns up anything you can't explain, that's not a ticket for the next sprint — it's an incident response engagement. Our SLA is a responder engaged within 30 minutes of a confirmed active breach, and a forged Domain Controller certificate is exactly the kind of finding that can't wait for a scheduled review.

The pattern: AD CS is the attack path scanners miss

We keep writing versions of this same post, because the lesson keeps repeating: we covered it three weeks ago when an unauthenticated RCE landed in Splunk, and again last week when an auth bypass hit Check Point's firewall management console. Certighost is the same shape of problem from a third direction: the systems that hold the most privilege in your environment are frequently the least tested, because they're internal, unglamorous, and "already trusted."

AD CS is a textbook example. It rarely makes it into a pentest scope explicitly — teams assume "we patch Windows" covers it — and a vulnerability scanner checking CA software versions won't tell you whether your enrollment permissions, template ACLs, or chase-target validation are actually safe. Three things close that gap:

• Put AD CS in explicit pentest scope, not just "internal network." When we scope a penetration test, certificate authorities, enrollment templates, and their ACLs are named targets. Certificate-based privilege escalation (ESC1 through ESC8-class issues, and now Certighost-class chase-target abuse) is some of the highest-value, lowest-noise access an attacker can get — which is exactly why a scanner's version check isn't enough and we run pure-manual engagements that actually walk the enrollment permission graph.
• Tier Active Directory before the next CVE forces the issue. Security hardening work — Tier 0 isolation for CAs and DCs, enrollment-agent restrictions, removing unused certificate templates — turns "any domain user can become a Domain Controller" into "the enrollment path doesn't exist in the first place." That's a control you build once, not a patch you chase every quarter.
• Know what your findings actually look like before you need them. A domain-compromise finding from an AD CS attack path reads very differently from a web app XSS in a report — see what a real pentest report looks like when the finding is "we became Domain Admin," including the evidence chain and remediation priority you should expect.

The one-line summary

CVE-2026-54121 lets any authenticated domain user impersonate a Domain Controller through AD CS and compromise the whole domain — patch every Enterprise CA to the July 2026 update today, audit replication logs for DCSync-style activity from non-DC hosts, and put certificate authorities in the same Tier 0 protection bracket as your Domain Controllers. Then ask whether your last pentest actually walked your AD CS enrollment permissions, or just checked that Windows Update ran.

---

Related reading

• CVE-2026-16232: Check Point's firewall console has an auth bypass — the same lesson from a different vendor: the management plane, not the gateway, is the real target.
• Why we still do pure-manual penetration testing — why a human walking the AD CS enrollment permission graph finds what a CA version scan misses.
• What a real penetration test report looks like — what the evidence chain and remediation priority should look like when a finding is full domain compromise.