CVE-2024-49019 in Microsoft ADCS: Detection and Remediation

Our AD CS Template Hardening: ESC1-ESC16 Defense Playbook covers CVE-2024-49019 as one entry among sixteen. It deserves its own focused treatment too, this is one of the more practical, easier-to-hit AD CS vulnerabilities disclosed in recent years, it doesn’t require a pre-existing template misconfiguration the way several other ESC patterns do, and a meaningful number of environments still haven’t fully remediated it well over a year after disclosure. This is a dedicated, standalone response guide: what’s affected, how the attack works at a conceptual level, how to patch, review templates, find evidence in your logs, and validate your remediation actually held.

TL;DR: Key Takeaways

CVE-2024-49019 (ESC15, “EKUwu”) was disclosed by TrustedSec researcher Justin Bollinger and patched by Microsoft on November 12, 2024: the underlying issue is in how AD CS handles Application Policy extensions on schema version 1 certificate templates.
It requires only enrollment rights, no template misconfiguration beyond being schema version 1: unlike ESC1, which requires a template specifically configured to let the requester supply their own subject, ESC15 works against ordinary, otherwise reasonably configured version 1 templates.
Several built-in default templates are schema version 1, including WebServer, meaning many environments carry this exposure without having done anything unusual with their template configuration.
Patching and template migration are complementary, not interchangeable, apply the November 2024 update to every CA, and separately identify and migrate remaining version 1 templates to version 2 or later, since cloning a version 1 template structurally removes this exposure.
CVE-2024-49019 is listed in CISA’s Known Exploited Vulnerabilities catalog, carrying mandatory remediation deadlines for federal agencies and widely used as a prioritization signal elsewhere.

What CVE-2024-49019 (ESC15/EKUwu) Actually Is

Disclosed publicly in October 2024, patched by Microsoft on November 12, 2024: researcher Justin Bollinger of TrustedSec identified the flaw and published technical details, with the CVE formally assigned around the time of the patch.
The core issue: Application Policy extensions can override a template’s configured EKU on schema version 1 templates: when both an Extended Key Usage value and an Application Policies extension are present in a certificate request, unpatched AD CS gives precedence to the Application Policies extension, an attacker who can include this extension in their request can effectively substitute their own intended use for the one the template was actually configured to allow.
Why version 1 templates specifically are exposed: the validation gap that allows this substitution applies to schema version 1 templates. Version 2 and later templates aren’t affected by this specific issue.
The practical bar for exploitation is low: ordinary enrollment rights against a vulnerable template are sufficient, no special permissions, no manager-approval bypass, and none of the more elaborate permission misconfigurations several other ESC patterns depend on.

Affected Configurations

Any unpatched CA hosting at least one schema version 1 template that’s actually enrollable, this is the core condition, patch level and template schema version together determine exposure.
Several built-in default templates carry schema version 1, WebServer among them, meaning this isn’t limited to custom or unusual template configurations, a stock, unmodified AD CS deployment can carry this exposure.
Templates that don’t require manager approval and are broadly enrollable represent the highest practical risk, since the low permission bar for exploitation means broad enrollment access directly translates to broad exposure.

Attack Path

The starting position is ordinary enrollment access, an account with standard, unremarkable permission to enroll against a vulnerable version 1 template, no elevated rights or unusual delegation required.
The exploitation mechanism, at a conceptual level: a certificate request against a vulnerable template includes an Application Policy value the requester chose, one different from what the template’s own configuration actually specifies. On an unpatched CA, that requester-supplied value takes precedence in the issued certificate.
The resulting certificate carries capability the template was never intended to grant, commonly cited examples in public research include client authentication, certificate request agent capability, and code signing, none of which the affected template’s own configuration was meant to provide.
From there, the escalation follows familiar certificate-based authentication abuse patterns, a certificate carrying unintended client authentication capability can potentially be used to authenticate as a different, more privileged identity, the same fundamental risk covered throughout our broader attack path guidance.

Patching

Apply Microsoft’s November 12, 2024 security update to every CA in your hierarchy, not just the ones most visible or most recently touched, a single unpatched CA still carries the underlying exposure.
Confirm patch level directly rather than assuming Windows Update coverage was complete, verify against your patch management system’s actual confirmation, particularly for any CA that may have been offline or excluded from a standard update cycle around the patch release window.
Treat this as a genuinely time-sensitive patching priority if you haven’t already applied it, given the low exploitation bar and CISA’s Known Exploited Vulnerabilities listing, this isn’t a patch to defer behind a routine maintenance cycle.

Template Review

Identify every schema version 1 template currently published and enrollable in your environment, using certutil or the PSPKI cmdlets covered in our PowerShell PKI module guide to query template schema versions across your CA hierarchy at scale rather than checking templates one at a time through the console.
Prioritize templates that are broadly enrollable and don’t require manager approval, these represent the most practically exploitable exposure and are worth addressing first if you can’t migrate every version 1 template simultaneously.
Migrate version 1 templates to version 2 or later where possible, cloning a version 1 template automatically upgrades its schema version, this structurally removes the exposure for that template independent of the CA-level patch, and is worth doing even on already-patched CAs as defense in depth.
Check whether Microsoft Defender for Identity is available in your environment, its certificate security posture assessment includes a specific recommendation addressing this exact vulnerability, flagging vulnerable templates automatically rather than requiring a fully manual review.

Event Evidence

Apply the Requester and Attributes correlation covered in our event ID 4886-4889 reference, specifically looking for certificates issued from templates that were never intended to support authentication carrying capability inconsistent with that template’s documented purpose.
Flag certificates issued from templates like WebServer that nonetheless carry client authentication, smart card logon, or certificate request agent capability, this mismatch between a template’s intended use and what its issued certificates actually carry is the central evidence pattern for this specific vulnerability.
Extend your log review back to well before your patch date, if any of your CAs were exposed for a meaningful period following the October 2024 public disclosure, your review needs to cover that full window, not just the days immediately around when you eventually patched.
Correlate suspicious issuance forward to authentication activity, using the same Event 4768/PreAuthType-16 correlation covered elsewhere in our series, to determine whether a suspicious certificate was actually used for authentication, not just issued.

Post-Remediation Validation

Confirm patch level on every CA explicitly, don’t rely on an assumption that a patch deployment completed successfully everywhere, verify directly against each CA.
Confirm no schema version 1 templates remain published without a documented reason, and that any that do remain have been reviewed specifically for this exposure and are appropriately restricted.
Run a controlled, benign validation test in a non-production environment, confirming a patched CA correctly enforces the template’s configured EKU rather than honoring a differing requester-supplied Application Policy, this is a legitimate defensive validation step and should only be performed in a test environment you control.
Re-run any available automated posture assessment, such as Microsoft Defender for Identity’s certificate security posture check, after remediation to confirm a clean result rather than relying solely on manual verification.
Build ongoing schema version monitoring into your standing template governance, so a newly created or restored version 1 template doesn’t silently reintroduce this exposure later, this is exactly the kind of drift our continuous risk assessment guidance is built to catch.

How Encryption Consulting Can Help

Confirming whether CVE-2024-49019 was ever actually exploited in your environment, rather than simply confirming you’re now patched, requires the same kind of CA database and event log correlation work covered throughout our incident-response guidance, and it’s easy to leave undone once patching alone feels like it closed the issue.

Encryption Consulting’s PKI Services team supports this directly:

Exposure assessment: identifying every schema version 1 template in your environment and confirming patch status across your full CA hierarchy.
Historical exploitation review: correlating certificate issuance and authentication logs for evidence this vulnerability was exploited before your environment was patched.
Template migration support: planning and executing version 1 to version 2+ template migrations, including handling any downstream re-enrollment or compatibility considerations.
Post-remediation validation, confirming your patch and template review actually closed the exposure, not just that the individual steps were performed.
Ongoing template governance, integrated into your broader continuous PKI risk assessment practice, so schema version drift doesn’t quietly reintroduce this or similar exposures later.

If you need help confirming your exposure to CVE-2024-49019 or validating your remediation, our PKI Services team can assist directly.

Conclusion

CVE-2024-49019 is a genuinely practical vulnerability, low permission bar, affecting stock default templates, and still incompletely remediated in a meaningful share of environments well over a year after disclosure. Patch every CA, identify and migrate remaining schema version 1 templates, review your certificate issuance history for evidence of exploitation before you patched, and validate the whole remediation rather than considering the job done once the update is installed. For the broader set of AD CS template risks this vulnerability sits alongside, see our complete ESC1-ESC16 hardening playbook.

Need help confirming your exposure to CVE-2024-49019 or validating your remediation? Talk to our PKI Services team for an assessment. Encryption Consulting is ISO/IEC 27001:2022 and SOC 2 certified.

FAQ

What is CVE-2024-49019? CVE-2024-49019, also known as ESC15 or EKUwu, is an AD CS elevation-of-privilege vulnerability disclosed by researcher Justin Bollinger of TrustedSec and patched by Microsoft on November 12, 2024. It allowed an attacker with only enrollment rights on a schema version 1 certificate template to inject an arbitrary Application Policy extension into a certificate request, overriding the template’s actual configured Extended Key Usage.

Which certificate templates are affected by CVE-2024-49019? Schema version 1 certificate templates specifically, including several built-in default templates such as WebServer. Version 2 and later templates are not affected by this specific issue, which is one reason migrating legacy version 1 templates forward is part of the recommended remediation alongside patching.

Does patching alone fully remediate CVE-2024-49019? Patching every CA with Microsoft’s November 12, 2024 security update addresses the underlying issue. Reviewing and migrating remaining schema version 1 templates to version 2 or later is a recommended complementary step, since cloning a version 1 template automatically upgrades its schema and removes this specific exposure structurally.

What should defenders look for in certificate issuance logs to detect CVE-2024-49019 exploitation? Look for certificates issued from templates that were never intended to support authentication, such as WebServer, that nonetheless carry Client Authentication, Smart Card Logon, or Certificate Request Agent capability. Correlating certificate issuance events against the template’s documented intended purpose is the core detection pattern.

Is CVE-2024-49019 listed as a known exploited vulnerability? Yes. CVE-2024-49019 has been included in CISA’s Known Exploited Vulnerabilities catalog, which carries mandatory remediation deadlines for U.S. federal agencies and is widely used as a prioritization signal by organizations more broadly.