Active Directory has one job, decide who gets to act as a domain controller. A flaw patched this month, tracked as CVE-2026-54121, let any authenticated user skip that decision entirely. No admin rights needed. Just a normal domain account and a little patience.

Microsoft fixed it quietly on July 14. Ten days later, the details went public. A working exploit script followed almost immediately.

What is CVE-2026-54121? A flaw in Active Directory Certificate Services that lets an authenticated, non-admin user obtain a certificate impersonating a domain controller. The bug lives in a fallback mechanism meant to help certificate requests succeed, and it trusts information an attacker controls.

A Fallback Feature Nobody Thought To Distrust

Certificate enrollment in AD CS normally works cleanly. Sometimes, though, the certificate authority can’t resolve who’s actually asking for a certificate on its own. For those cases, Microsoft built a fallback called “chase.” It lets the requester supply two attributes, cdc and rmd. Those point the CA toward a specific domain controller and machine object to check.

The CA followed that pointer without verifying it led anywhere legitimate. An attacker could stand up a rogue SMB and LDAP service. From there, fake identity details go straight to the CA through those attributes. The attacker then walks away with a certificate that says “domain controller” on it. Nothing about the request looked forged, because the CA never checked whether the server on the other end was real.

From Fake Certificate To Full Domain Takeover

A rogue certificate alone doesn’t end the story. It’s the starting point. The public exploit tool, certighost.py, chains several steps together automatically.

First, it creates a machine account. Most domains allow any authenticated user to create up to ten of these by default, through a setting called ms-DS-MachineAccountQuota. The tool then submits a crafted certificate request, using that fake account to trigger the vulnerable fallback. Once it holds a domain-controller certificate, it authenticates as one through PKINIT. From there, it runs a DCSync attack, pulling the krbtgt account’s secret straight out of Active Directory.

That last step matters more than any other in this chain. Whoever holds the krbtgt secret can forge Kerberos tickets for any account in the domain, administrators included. Security teams call this a golden ticket. It survives password resets. Only changing the krbtgt secret itself, twice in a row, actually closes it.

A Five-Day Sprint From Patch To Public Exploit

This flaw was reported to Microsoft back in May. They confirmed it about a week later. The actual fix landed quietly in July’s Patch Tuesday, folded in among dozens of other updates.

Public disclosure came ten days after that patch, on July 24. A working exploit script followed almost immediately. That gap between “patch available” and “attack tooling public” keeps shrinking across the industry. This flaw is one more data point for that trend.

The fix itself rejects the kind of malformed input the attack depends on. That means rejecting IP addresses where a hostname belongs, names that run too long, and stray LDAP metacharacters. None of that validation existed before July. Administrators who can’t patch immediately can disable the chase fallback as a stopgap. Microsoft’s own guidance treats that as a bridge to the real fix, not a replacement for it.

Why This Is A Trust Problem, Not Just A Bug

Certighost isn’t really about a coding mistake. It’s about a system that trusted information it should have verified first. The certificate authority took an attacker’s word for who a server was, then issued credentials based on that word alone.

That’s the same failure mode behind a lot of identity-based attacks: a system grants trust before confirming it’s deserved. Zero Trust architecture exists specifically to close gaps like this one. It treats every request as unverified until proven otherwise, no matter where inside the network it originates. A decade-old convenience feature turned into exactly the kind of blind trust Zero Trust architecture is built to eliminate.

Conclusion: When a Valid Certificate Proves the Wrong Identity

Certighost shows how completely identity security can fail when a trusted authority verifies the wrong source.

On an unpatched Active Directory Certificate Services environment, a low-privilege domain user can direct the certificate authority toward attacker-controlled SMB and LDAP services. The CA can then issue a valid certificate that identifies the attacker as a domain controller.

The certificate is legitimate.
The identity behind it is not.

Why This Threat Matters

CVE-2026-54121 turns an ordinary domain account into a path toward full Active Directory compromise.

• No administrative privileges are required
• No user interaction is needed
• Attacker-controlled cdc and rmd attributes steer the trusted fallback
• Default machine-account creation rights can provide the identity needed to begin
• A forged domain-controller certificate enables authentication through PKINIT
• Domain-controller identity can provide a path to DCSync
• Access to the krbtgt secret enables Golden Ticket creation
• Normal user password resets do not remove forged Kerberos trust
• Public exploit tooling has reduced the time defenders have to patch

This is not only certificate abuse. It is a trust decision that can place the entire domain under attacker control.

Where Xcitium Changes the Outcome

This attack must be addressed at three points, before the vulnerable certificate authority remains exposed, before false identity becomes privileged access, and before exploit tooling runs across managed systems.

Xcitium Vulnerability Assessment helps organizations identify vulnerable Windows servers, missing security updates, and patch gaps affecting systems that host critical identity infrastructure such as AD CS.

Xcitium ITDR strengthens the identity layer by helping security teams identify abnormal machine-account creation, suspicious certificate-based authentication, unexpected domain-controller identity use, replication activity, and privileged access that no longer matches expected behavior.

A valid domain account should not end identity verification.
A CA-signed certificate should not make abnormal behavior trustworthy.
Authentication should not be the final security decision.

When attackers use unknown scripts, PoC tools, credential utilities, or follow-on payloads on managed systems, Xcitium Advanced EDR, powered by Xcitium’s patented Zero-Dwell platform, applies Execution Governance.

Unknown code does not receive unrestricted execution rights.
Code can run without being able to cause damage.
Runtime behavior is governed before trust exists.
Security teams gain evidence of what unknown execution was prevented from affecting.

Detection asks, “Was a valid certificate presented?”

Identity security asks, “Does this activity belong to the identity represented by that certificate?”

Execution Governance asks, “Should the code driving this activity receive unrestricted access at all?”

Together, these controls prevent one low-privilege account from becoming unrestricted domain control.

Patch the Authority. Rebuild the Trust.

Certighost proves that internal identity infrastructure cannot be trusted simply because it issued a technically valid credential. Trust must depend on verified origin, expected behavior, and continuously enforced policy.

Apply the July 2026 security updates to affected systems.
Treat disabling the chase fallback only as a temporary bridge to patching.
Review machine-account creation rights and certificate enrollment activity.
Hunt for suspicious cdc and rmd request attributes.
Investigate unexpected PKINIT and DCSync behavior.
Revoke malicious certificates immediately.
If domain compromise is suspected, rotate the krbtgt secret twice using a controlled recovery process.
Govern unknown execution on systems used to administer identity infrastructure.