Windows CVE-2024-49113, nicknamed LDAPNightmare, is an LDAP-related LSASS crash vulnerability Microsoft patched on December 10, 2024. It is a sibling of CVE-2024-49112, a CVSS 9.8 LDAP client RCE patched the same day. SafeBreach published a PoC on January 1, 2025, that reliably crashes LSASS on unpatched domain controllers through a crafted LDAP referral response, which translates to a forced reboot and a denial-of-service against authentication for the entire forest until the DC recovers. The combination of the pair makes this one of the most important Windows December 2024 updates.
What is the actual flaw in CVE-2024-49113?
CVE-2024-49113 is an out-of-bounds read in the Windows LDAP client processing code that triggers when a server returns a crafted referral response. When a Windows domain controller or client performs an LDAP query that receives a referral, the client parses the referral URL and related fields. The parser incorrectly trusts a length field in the response, leading to an out-of-bounds read that dereferences garbage memory and crashes the LSASS process. LSASS is the Local Security Authority Subsystem; on a domain controller, crashing LSASS causes the system to reboot automatically.
The more severe sibling, CVE-2024-49112, is an integer overflow in the same code path that leads to memory corruption usable for remote code execution. Microsoft patched both with the December 2024 cumulative updates (KB5048667 and related). The CVSS 9.8 rating on CVE-2024-49112 reflects that a malicious LDAP server can compromise any Windows client that initiates an LDAP connection to it.
How does the attack chain play out against a domain controller?
The attack chain plays out by inducing a target domain controller to perform an LDAP query against an attacker-controlled server that returns the crafted referral response. The hard part for attackers used to be "how do I make a DC query my server," but SafeBreach's PoC chain uses DNS SRV records and DsrGetDcName RPC to trigger the outbound LDAP from the DC without prior authentication or access to that DC's network.
The full chain:
- Attacker sends an RPC request to a target DC's Netlogon interface asking the DC to locate a DC in a fake domain
- DsrGetDcNameEx2 triggers a DNS query for SRV records of that domain
- Attacker controls the DNS response and returns the IP of their LDAP server
- The target DC initiates an LDAP connection to the attacker's server
- The attacker's LDAP server returns a crafted referral response
- The target DC's LDAP client parses the response, hits the out-of-bounds read, LSASS crashes, DC reboots
For CVE-2024-49113, the endpoint result is denial of service. For CVE-2024-49112, swapping the exploit for the integer-overflow variant results in code execution in LSASS context, which on a DC is essentially full forest compromise because LSASS holds all the Kerberos keys.
Why is LSASS on a domain controller such a bad place for an OOB read?
LSASS on a domain controller is the process that handles every Kerberos, NTLM, and LDAP authentication for the forest, and crashing it causes an automatic system reboot. A domain with only one DC becomes unreachable for five to ten minutes. A larger domain sees authentication storms as clients retry against other DCs, with Group Policy processing failing and Kerberos ticket issuance pausing. An attacker with network access to trigger the chain repeatedly can maintain DC unavailability indefinitely, which is catastrophic for business operations dependent on AD.
The RCE variant is worse because LSASS holds the encryption keys for the Active Directory database. Code execution in LSASS context gives the attacker:
- All user password hashes (NTDS.dit)
- Kerberos TGT signing keys (krbtgt)
- Machine account credentials
- Stored credentials for service accounts
In other words, the attacker becomes the domain. Recovery from that state is a full forest rebuild, not a password reset.
Which environments are most exposed to LDAPNightmare?
Environments most exposed are those where DCs can be induced to perform outbound LDAP queries to arbitrary destinations, which is a surprisingly common configuration. Specifically:
- DCs that can resolve external DNS (most of them)
- DCs where egress LDAP (TCP 389 and 636) is not restricted
- Multi-domain forests with trusts whose DNS resolution paths cross network boundaries
- DCs exposed to guest networks through shared DNS or DHCP
Azure AD Connect and hybrid configurations add attack surface because the on-prem DC regularly performs LDAP queries related to sync operations. Cloud-only environments are not exposed to this specific CVE because there are no on-prem DCs, but hybrid shops with even one DC are in scope.
The PoC works against fully patched Windows Server 2019, 2022, and Windows 10 and 11 clients before the December 2024 update. The patched version behavior is that the LDAP client rejects the malformed referral response, logs an event, and continues normal operation.
What detection and hardening works before and after patching?
Detection and hardening work on three layers: egress filtering, DNS monitoring, and LSASS telemetry. Egress filtering is the single most effective control: if your DCs cannot reach arbitrary DNS resolvers or arbitrary LDAP servers on the internet, the chain dies at step 3. Block outbound DNS from DCs to anything except your internal resolvers, and block outbound TCP 389 and 636 from DCs to anything except your trusted forest members.
DNS monitoring detections:
- DCs performing SRV lookups for
_ldap._tcp.dc._msdcs.<unknown_domain>where the domain is not a known trust - Spike in outbound DNS queries from DCs to non-internal resolvers
- DCs resolving A records for domains the organization does not use
LSASS telemetry:
- Windows event 4001 (LSASS terminated unexpectedly) on a DC is a five-alarm fire
- Event 1074 (system reboot due to system crash) on a DC outside patching windows
- Windows Error Reporting crash dumps from
lsass.exe
Post-patch, the patched DC logs event 2886 from the LSA source when it rejects a malformed LDAP referral. Monitoring for that event gives you visibility into attempted exploitation attempts against patched hosts.
What supply chain and TPRM issues follow from this CVE?
Supply chain issues follow because many applications and appliances embed Windows LDAP client libraries or call into them via COM. Every Windows-based third-party application that performs LDAP lookups inherits the risk of the local LDAP client code path. If a vendor's product runs on a DC or on a Windows system that joins the domain and has not applied the December 2024 cumulative, it is a target for induced LDAP exploitation.
TPRM questions to ask vendors who deploy Windows-based appliances:
- What Windows patch level is shipped and how is it updated?
- Does the appliance restrict outbound DNS and LDAP?
- Is the appliance ever deployed on or near a domain controller?
Appliances that were stuck on older Windows cumulative updates due to vendor validation cycles are the most common gap. Several backup, monitoring, and identity products took weeks to ship updated appliance images after the December 2024 patches.
How Safeguard.sh Helps
Safeguard.sh enumerates every Windows host and appliance in your environment running below the December 2024 cumulative update through 100-level scanning that covers both managed endpoints and third-party appliances that ship pre-built Windows images. Reachability analysis eliminates 60 to 80 percent of findings by identifying which hosts are in a position to perform outbound LDAP or DNS against attacker-controlled infrastructure, so remediation priority focuses on DCs and Windows systems with broad egress. Griffin AI autonomously generates firewall and DNS policy recommendations tuned to your topology, opens TPRM tickets for vendors shipping lagging Windows images, and container self-healing rebuilds affected Windows container images. SBOM generation and ingest cover Windows binary components alongside Linux packages for a unified picture of exposure.