Author: Len Noe, Solutions Architect, BeyondTrust

Every mature Active Directory environment has a component that quietly holds more power than the people running it usually admit: the Certification Authority (CA). The thing your entire estate has agreed to believe.

When it signs a certificate, every machine, service, and authentication flow downstream treats that signature as truth. That is an enormous amount of trust concentrated in one system, and most organizations manage it like a utility installed once and never thought about again.

Certighost, tracked as CVE-2026-54121, is a reminder of what happens when that trust is misplaced. Researchers published a working proof-of-concept on July 24, 2026, demonstrating that a low-privileged Active Directory user (holding nothing more than a standard domain account) can coerce an Enterprise CA into issuing a valid authentication certificate for a Domain Controller, then use that certificate to become the Domain Controller.

Microsoft shipped the fix on July 14, 2026, and rated it 8.8 on the CVSS scale.

What Certighost actually does

Active Directory Certificate Services is Microsoft's public key infrastructure, issuing and managing the certificates that underpin smart card logon, device and user authentication, and VPN access. A standard domain user has no business obtaining a certificate that represents a Domain Controller, yet Certighost breaks that boundary without touching a single access control list.

The flaw lives in an AD CS enrollment behavior known as "chase" functionality. When an Enterprise CA cannot immediately resolve the target object locally, it can follow requester-supplied routing information (a parameter called cdc) to look the object up elsewhere.

The defect is that the CA never verifies that the endpoint named in cdc is a legitimate Domain Controller before it reaches out to it. An attacker points cdc at a machine they control and the CA dutifully makes an outbound connection to that rogue endpoint, which answers with forged identity data, including the target Domain Controller’s object security identifier and DNS host name.

The CA trusts what it is told, binds that identity to a signed X.509 certificate, and hands the attacker a certificate that says they are a Domain Controller.

From there, the attack follows a well-understood path. The attacker uses the certificate with PKINIT, the public key extension to Kerberos, to obtain a Ticket Granting Ticket as the Domain Controller's machine account.

Domain Controller accounts inherently hold directory replication rights, enough to run a DCSync operation against a real DC and pull credential material, up to and including the krbtgt account hash. Once you have krbtgt, you can forge Kerberos tickets at will, and the domain is functionally yours.

A standard Domain User account was sufficient in testing because default Active Directory settings, including the default MachineAccountQuota that lets ordinary users create machine accounts, provided everything the chain needed.

As of public disclosure, there was no confirmed exploitation in the wild. That is not a reason to relax. A functional, public proof-of-concept collapses the effort required to reproduce this, and the gap between "PoC exists" and "commodity tooling includes it" is measured in weeks, not years.

Certighost exposed how privilege buried in trusted relationships and overlooked defaults can become a path to domain compromise.

BeyondTrust’s complimentary Identity Security Risk Assessment helps you uncover those hidden identity and privilege exposures across your own environment before they become the next path attackers exploit.

Find Your Hidden Risk## This is not a certificate bug. It is a privilege and trust failure.

It is tempting to file Certighost under PKI arcana, assign it to whoever owns the CA, and move on once the patch lands.

Strip away the certificate machinery and look at the shape of the attack: an unprivileged identity manipulated a trusted system into vouching for a privileged identity, and the environment had no mechanism to question the result. That is a trust-validation problem that sits at the core of identity security.

The Certification Authority is not a passive appliance. It is a privileged identity in its own right, one that manufactures trust on behalf of the entire domain. The patch Microsoft shipped is, at its heart, a verification step enforcing that the target of a chase lookup is genuinely a Domain Controller.

That is the recurring signature of identity-driven compromise: the attacker rarely breaks cryptography or authentication. They find the place where the system decided to trust without checking.

There is a second, more uncomfortable lesson buried in the prerequisites. The default configuration of Active Directory grants every authenticated user a small piece of standing privilege: the ability to create machine accounts, courtesy of a MachineAccountQuota that permits it by default.

Certighost is one of many attack chains that quietly depend on that standing capability. The specific CVE is new, but the latent privilege it leaned on has been sitting in your domain for years.

The vulnerability created a shortcut, but the terrain was already dangerous.

A determined attacker who lands a single low-privileged foothold has a realistic path to domain dominance because privilege has accumulated in places no one is actively governing: overbroad certificate template permissions, permissive machine account defaults, flat trust between the CA and the domain, and monitoring that watches endpoints but not the identity control plane.

Certighost is a clean demonstration of how those conditions compound. Remove the CVE and the underlying exposure remains, waiting for the next technique.

What to actually do about it

Patch first. Apply Microsoft's July 14, 2026 update to every issuing Certification Authority because it introduces the destination validation that shuts down the specific chase abuse.

If deployment is delayed, researchers documented a workaround that disables the vulnerable chase functionality. But test it before you deploy it: that path exists to support legitimate enrollment workflows, and turning it off can break them.

Beyond the immediate fix, reduce the standing privilege the attack relied on. Setting the domain's MachineAccountQuota to zero removes the default ability for ordinary users to create machine accounts, meaningfully shrinking the attack surface for this class of technique.

That change is not free. Some provisioning workflows and legacy tooling assume users can join machines to the domain, so inventory those dependencies and route machine creation through controlled, delegated accounts rather than leaving it open to everyone.

Then constrain the CA itself. Restrict outbound SMB and LDAP from your Certification Authorities so they can only communicate with known, authorized Domain Controllers, which directly undercuts the rogue-endpoint step in the chain.

Review Enterprise CA deployments, certificate templates, and enrollment permissions: which principals can request this, and does that population have any business holding the identity this certificate represents?

Most environments have never audited certificate enrollment rights against that standard, and that is precisely where AD CS attack paths originate.

Finally, watch the right layer. Monitor for anomalous machine account creation, unusual certificate enrollment activity, and DCSync operations, and pay attention to CA enrollment events rather than assuming endpoint telemetry will catch an identity attack it was never designed to see.

DCSync from anything other than a Domain Controller deserves an immediate response, and if your detection stack cannot surface it, that is a gap worth closing.

The real takeaway

Certighost will be patched, cataloged, and largely forgotten within a quarter. That is the trap. If the response stops at the KB number, the organization learns nothing durable because the specific bug was never the point. The point is that trust in an enterprise is a thing you architect and continuously validate, not a property you configure once and inherit forever.

The defensible posture is not a longer patch list. It is a mindset that treats identity as infrastructure and privilege as risk to be minimized rather than convenience to be preserved. Reduce standing privilege wherever it hides, including the defaults you never chose, and validate trust at every point where a system is about to act on it, not just at the front door.

Your Certification Authority has been handing out trusted identities on your behalf since the day it was stood up. The work is making sure it only does so for identities you can actually verify.

Learn how BeyondTrust’s complimentary Identity Security Risk Assessment helps you uncover those hidden identity and privilege exposures across your own environment.

About the Author

Len Noe is a Solutions Architect at BeyondTrust, Transhuman, Podcaster, International Cyber Security Speaker, Author, Technical Evangelist, and Biohacker with 13 implanted microchips.

A former blackhat with more than 30 years in technology, he has presented in over 70 countries and is featured in the documentary I Am Machine, which premiered at DEF CON 2025.

BeyondTrust is the global leader in privilege-centric identity security protecting Paths to Privilege™. Identity alone doesn’t create risk. Privilege does. As human, machine, and AI agent identities explode across every environment, BeyondTrust is the only company built to discover, control, and secure privilege across all of them from a single platform. Trusted by 20,000+ customers, including 75 of the Fortune 100, and recognized as a multi-category leader by top industry analysts, BeyondTrust reframes identity security from a management problem into a strategic advantage.

Learn more at www.beyondtrust.com.

Sponsored and written by BeyondTrust.