Certighost: an ordinary domain user turns the certificate authority into a domain controller

Every mature Active Directory infrastructure contains a component whose power the administrators themselves tend to underestimate — the certificate authority (CA). When it signs a certificate, every machine, service and authentication flow downstream accepts that signature as truth. The Certighost vulnerability (CVE-2026-54121) is a reminder of what happens when that trust turns out to rest on nothing.

How the attack works

On July 24, 2026, researchers published a working proof-of-concept: a user with an ordinary domain account and no additional privileges whatsoever can force an enterprise CA to issue a valid authentication certificate for a domain controller — and then use it to become that controller.

The flaw is hidden in the enrollment request redirection mechanism known as “chase.” When a CA cannot find the target object locally, it follows the routing information supplied by the requester (the cdc parameter) and reaches out to the specified node for data. The problem is that the CA never checks whether that node is actually a legitimate domain controller. The attacker points cdc at their own machine, which responds with forged identity data — the SID and DNS name of the desired controller — and the CA dutifully binds that identity to a signed X.509 certificate.

From there the path is well known. Through PKINIT the certificate is exchanged for a Kerberos ticket on behalf of the controller's machine account, and such accounts hold directory replication rights. A DCSync operation against the real controller lets the attacker pull credentials all the way down to the krbtgt hash — at which point the domain effectively belongs to the attacker. An ordinary user was enough, because the MachineAccountQuota parameter by default allows anyone to create machine accounts.

It's not about certificates

Microsoft released a fix on July 14, 2026, rating the vulnerability at 8.8 on the CVSS scale; the patch adds a check that the target of a chase request really is a domain controller. There were no confirmed cases of exploitation in the wild as of disclosure, but the public PoC sharply lowers the barrier to entry.

The author stresses that the temptation to reduce it all to a KB number and forget about it is the real trap. The vulnerability is new, but the privilege it relied on had been sitting in the domain for years. The attacker here isn't breaking cryptography — they're finding the place where the system decided to trust without verifying. The certificate authority is itself a privileged identity, manufacturing trust on behalf of the entire domain.

What to do

The first step is to install the July update on all issuing CAs. If deployment has to be postponed, there is a documented workaround — disabling the vulnerable chase feature — but it needs testing, since the feature supports legitimate enrollment scenarios. Next, it's worth trimming back the background privileges: setting MachineAccountQuota to zero removes rank-and-file users' right to create machine accounts, though this may break some domain-join processes. It also helps to restrict outbound SMB and LDAP from the CA to trusted controllers only, review permissions on certificate templates, and set up monitoring for anomalous machine account creation, unusual enrollment and DCSync operations — especially DCSync originating from something other than a domain controller.

The overall takeaway is simple: trust in an enterprise environment is something you design and continually verify, not a property you configure once and inherit forever.

Source: Bleeping Computer