Certighost turns a domain user into a Domain Controller, and the patch is only step one

Researchers published a working proof-of-concept on July 24, 2026 for Certighost, tracked as CVE-2026-54121, showing that an Active Directory user holding nothing more than a standard domain account can coerce an Enterprise Certification Authority into issuing a valid authentication certificate for a Domain Controller, then use that certificate to become the Domain Controller ^[1]. Microsoft shipped the fix on July 14, 2026 and rated the flaw 8.8 on CVSS ^[2], which gave defenders ten days between patch and public exploit code ^[3].

The account of the mechanism comes from Len Noe, a solutions architect at BeyondTrust, writing on BleepingComputer. The defect sits in an AD CS enrollment behaviour called "chase": when an Enterprise CA cannot resolve the target object locally, it follows requester-supplied routing information in a parameter named cdc to look the object up somewhere else ^[4]. The CA never verifies that the endpoint named in cdc is actually a Domain Controller, so an attacker points cdc at a machine they control ^[5]. The rogue endpoint answers with forged identity data, including the target Domain Controller's object security identifier and DNS host name ^[6], and the CA binds that identity into a signed X.509 certificate ^[7]. No access control list is touched anywhere in the chain ^[8].

What follows is routine. The certificate is used with PKINIT, the public key extension to Kerberos, to obtain a Ticket Granting Ticket as the Domain Controller's machine account ^[9]. Machine accounts for DCs inherently carry directory replication rights, which is enough to run DCSync against a real DC and pull credential material up to the krbtgt hash, after which Kerberos tickets can be forged at will ^[10]. Noe notes that a standard Domain User sufficed in testing because default Active Directory settings supplied the rest, including the default MachineAccountQuota that lets ordinary users create machine accounts ^[11].

Read the patch for what it is. According to Noe, Microsoft's fix is at heart a verification step enforcing that the target of a chase lookup is genuinely a Domain Controller ^[12]. That closes one missing check inside the CA. It does not change the shape of the problem the same piece identifies: an unprivileged identity talked a trusted system into vouching for a privileged identity, and the environment had no mechanism to question the result ^[13]. Noe's framing is that this is not a certificate bug but a privilege and trust failure, and that the CA is a privileged identity in its own right rather than a passive appliance ^[14].

So the post-patch work is enrollment hygiene, and it is yours, not Microsoft's. The source does not enumerate a hardening checklist, and we are not going to invent one. But two of its own load-bearing details point at configuration you can inspect today: MachineAccountQuota was still at its default and that default was part of the chain ^[11], and the estate had no way to challenge a certificate that asserted DC identity ^[13]. Knowing which principals can enrol against which templates, and whether anything downstream would notice a DC certificate arriving from a workstation, is the part a monthly patch cycle does not do for you.

There was no confirmed exploitation in the wild as of public disclosure ^[15]. Noe's own estimate is that the gap between a functional public PoC and commodity tooling is measured in weeks rather than years ^[16], which is the interval to plan against. Worth noting the provenance: the piece ends by promoting BeyondTrust's complimentary Identity Security Risk Assessment ^[17], so treat the diagnosis as sound and the framing as sold.