Certighost Isn’t the Real Story. Your Unreviewed AD Defaults Are.

Certighost, the AD CS privilege escalation flaw disclosed this week, will get patched. Most affected organisations will apply Microsoft’s July update within a few weeks, then move on. That is the wrong lesson to take from it. The bug that let a normal domain user impersonate a domain controller only worked because of a Windows default almost nobody reviews. That default is still sitting there in most Active Directory environments today, patch or no patch.

The AD CS privilege escalation bug, briefly

Tracked as CVE-2026-54121 and rated 8.8 on the CVSS scale, Certighost exploits a gap in Active Directory Certificate Services. The gap sits in a fallback identity lookup called a chase. Researchers H0j3n and Aniq Fakhrul found that the certificate authority trusted identity details the requester supplied. It never checked those details came from a genuine domain controller.

An attacker with an ordinary domain account, and nothing more, could get a certificate issued for a real domain controller’s identity. From there they could pull the krbtgt secret. They could then forge Kerberos tickets for any account in the domain. Microsoft fixed the verification gap in its 14 July 2026 update, ten days before the researchers published a working exploit. That is a good disclosure timeline. It is also not the part of this story that should worry you most.

The default nobody touches

Every step of this attack needed one more thing besides the AD CS bug itself: a computer account the attacker controlled. Windows lets any authenticated domain user create up to ten computer accounts by default. This setting is called the machine account quota. It exists for a fair reason. Regular staff can join their own devices to the domain without calling IT.

Almost no organisation has ever set that quota to zero, because almost no organisation has ever had cause to think about it. Yet that is exactly the kind of setting attackers rely on. It is also exactly the kind of setting a scoped penetration test is built to surface.

Certighost needed a specific AD CS code path to work. But plenty of other Active Directory attacks, from Kerberoasting to Resource-Based Constrained Delegation abuse, lean on this same quiet default. Patch Certighost, and the machine account quota is still wide open. Whatever comes after Certighost, and something always does, will likely lean on it again. It is the same pattern behind other local privilege escalation bugs we have covered: a named flaw gets fixed, while the everyday setting that made it dangerous goes unreviewed.

Why “we patched it” is not “we checked it”

Patching closes the specific hole Microsoft found. Your certificate templates might still be scoped too broadly, and nothing in this fix checks that. The default Machine template might still be open to more users than it needs to be, and the July update leaves that untouched too. Whether your domain would survive an attacker who already holds one low-privileged account is a separate question entirely. That is the starting position in most real intrusions, once phishing or credential stuffing succeeds.

Vulnerability management answers one question: did we apply the fix. Rarely does it answer the harder one, which is whether this environment would hold up against someone who is already inside. That second question is what an Active Directory penetration test is for. A tester who already has one standard domain account, the same starting point Certighost assumed, can answer that within days. They check your machine account quota, certificate template permissions and delegation settings for the same gap. Patched or not, that gap is worth knowing about before an attacker finds it for you.

What this means for AD CS privilege escalation risk generally

Bugs like Certighost earn headlines because they have a name and a CVE attached. Misconfigured defaults that enable AD CS privilege escalation get exploited just as often, yet rarely earn either. So patch the AD CS servers this week. That part is not optional. Then go further than the patch:

• Check your domain’s machine account quota, and reduce it if staff do not genuinely need self-service device enrolment.
• Review which certificate templates allow enrolment by any authenticated user, rather than a defined group.
• Ask when Active Directory was last tested from the perspective of someone who already has a standard user account, not just from the outside.

Certighost will likely be forgotten within a year. The default that made it possible will still be there, unless someone deliberately goes looking for it. Treat every future AD CS privilege escalation disclosure the same way: patch fast, but ask what else in the same environment made the patch necessary in the first place.