Title: New LSASS DoS (CVE-2025-53716) — What admins need to know now
By WindowsForum.com security desk — August 12, 2025
Summary
- A null-pointer dereference vulnerability in the Windows Local Security Authority Subsystem Service (LSASS) — tracked as CVE-2025-53716 in Microsoft’s Security Update Guide — can be triggered by an authorized attacker to cause a denial of service (crash/reboot) over the network.
- Microsoft’s advisory is the authoritative source; security teams should treat this as an immediate patch-and-mitigate item for any systems that run LSASS as a network-facing service (notably Domain Controllers and other authentication servers).
- Practical defenses while you patch: prioritize Domain Controllers, block untrusted CLDAP/LDAP discovery traffic at the perimeter, harden name-resolution paths, enable EDR/telemetry for LSASS crashes, and schedule a tested update window. See recommended steps below.
LSASS (lsass.exe) is the Windows system process responsible for enforcing security policy, validating logons, managing authentication tokens, and more. Any bug that causes LSASS to crash can cascade into large-scale authentication failures, domain controller reboots, outage of Active Directory services and, in the worst case, enterprise-wide service disruption. Microsoft’s advisory for CVE-2025-53716 describes a null pointer dereference in LSASS that an authorized attacker can cause over a network — in short, an attacker with valid access can crash LSASS and deny service to affected machines.
Technical breakdown (what “null pointer dereference” means here)
- Null pointer dereference (CWE-476) is a class of memory bug where code attempts to read or write memory through a pointer that contains zero (NULL). When kernel or critical service code dereferences NULL unexpectedly, the affected thread or process typically crashes. In user-mode services such as LSASS, that crash can force a service termination and, on systems like Domain Controllers, can trigger an automatic reboot or widespread authentication failures. Microsoft’s public description for this CVE explicitly calls out a null pointer dereference in LSASS that can be invoked by an authorized network attacker.
- Important nuance: Microsoft’s wording (“authorized attacker”) usually means the attacker must be able to authenticate or otherwise present valid credentials or be on a privileged network path that the vulnerable service trusts. That restriction reduces the blast radius compared with unauthenticated remote exploits, but does not make the bug benign. Any attacker able to leverage that vector inside your network (or who can trick internal name-resolution flows into talking to attacker-controlled infrastructure) can still cause real outages.
- Denial-of-service against LSASS is disruptive even when it requires “authorized” access: compromised user accounts, misconfigured network services, or exposed discovery flows (DNS/SRV/CLDAP) are common ways attackers get the necessary foothold. Past LSASS-related DO S and LDAP referral exploits have shown how discovery/name-resolution behaviors can be abused to produce zero- or low-click impact on domain infrastructure.
- The U.S. Cybersecurity and Infrastructure Security Agency (CISA) and multiple incident trackers routinely highlight LSASS/LSA issues as high-priority because of their systemic impact on authentication and directory services. If you run domain controllers, treat this as high-priority patching work.
- If you are managing internet‑facing or poorly segmented domain services, the realistic attack scenarios include: (a) an attacker who has stolen or phished credentials and can send crafted requests, or (b) network-based manipulation of discovery flows (DNS/CLDAP) that causes LSASS to process attacker-controlled data. Blocking or carefully controlling discovery flows is therefore a practical mitigation while you deploy patches.
- Microsoft’s Security Update Guide page for CVE-2025-53716 is the canonical reference for the exact list of affected SKUs and updates; consult that page for the KB/CU/patch numbers that apply to your builds. (MSRC: CVE-2025-53716).
- Historically, LSASS-related bugs most severely impact Domain Controllers, Windows Server builds, and servers that provide authentication or identity services (including some RDS/AD-integrated services). Even client OSes can experience denial-of-service effects if LSASS crashes. Treat domain controllers as the highest priority in your estate.
1) Confirm Microsoft’s fix and identify the updates that fix CVE-2025-53716
- Open Microsoft’s Security Update Guide entry for CVE-2025-53716 and note the KB/cumulative update packages and the “affected products” table for exact SKUs and build numbers. Apply the vendor-supplied cumulative updates or servicing stack updates Microsoft lists for your OS builds as soon as you can safely do so.
- Patch domain controllers first in a controlled manner. Schedule a maintenance window and have rollback/recovery procedures ready because rebooting DCs can affect the whole environment. If you can’t patch immediately, isolate DCs from untrusted networks and reduce their exposure to discovery flows.
- CLDAP and LDAP referral flows have been abused in prior LSASS/LDAP chains. If your environment does not require CLDAP (connectionless LDAP over UDP 389) to talk to untrusted networks, consider blocking outbound CLDAP (UDP 389) from domain controllers at your perimeter firewall and block LDAP/CLDAP connectivity to the Internet. This reduces the chance that external name-resolution/DNS tricks can provoke vulnerable referral handling.
- Ensure DC DNS configurations prefer internal, trusted DNS servers and do not resolve external SRV records that can be manipulated by attackers. On multihomed hosts, review DNS suffixes, forwarders, and conditional forwarders; avoid forwarding SRV lookups to untrusted external resolvers.
- Tune EDR to alert on unexpected lsass.exe crashes, repeated service termination events, mass authentication failures, or sudden Domain Controller reboots. Collect and preserve logs for any LSASS crash: System and Application event logs, EDR telemetry, Sysmon process termination events, and any network captures around the time of the event. These signals help you detect exploitation attempts and support post‑incident forensics. (See “What to monitor” below.)
- Apply patches first to test/dev and limited production groups. Confirm stability, then roll out to the rest of the estate. If a patch combination causes a regression, follow Microsoft’s KB guidance for Known Issue Rollback (KIR) or apply the recommended servicing stack / compatibility updates before broad deployment.
- Event logs showing LSASS termination or service crashes (System/Application): unexpected lsass.exe process exits, service termination events, BSODs or bugcheck reports on affected servers, and repeated auth failures across the domain. These are primary indicators of an LSASS crash. (Collect event timestamps and correlated network telemetry when available.)
- EDR/SIEM indicators: sudden process terminations of lsass.exe, anomalous RPC/DCE traffic patterns that include CLDAP/LDAP referral flows, and unusual DNS SRV resolution to unknown external servers.
- Network telemetry: spikes in CLDAP/LDAP UDP 389 traffic, unexpected outbound LDAP/CLDAP connections to external IPs, or a surge of discovery-related DNS SRV queries.
- If you have packet captures from the incident window, search for crafted CLDAP/LDAP referrals or malformed payloads that appear immediately before the LSASS crash — these are common in previous referral-based LSASS/LDAP exploit chains.
- Isolate the affected host from the network (if it’s not a Domain Controller in the middle of active replication) to prevent lateral movement or repeated abuse.
- Preserve volatile data: memory image and EDR logs, event logs, and any captured network traffic. Do not reboot or reimage until you’ve captured relevant forensic artifacts unless mandated for safety.
- If a DC is affected and you must restore authentication services quickly, bring up a healthy backup DC (patched) and ensure replication is healthy; avoid reintroducing an unpatched, crashing DC to the domain without addressing the vulnerability.
- LSASS has been a recurring target: historical incidents and research have shown both DoS and RCE chains using LDAP/CLDAP referral manipulation and other name-discovery abuse. In late 2024 / early 2025, security researchers publicly demonstrated referral‑based crash and RCE chains against LDAP and LSASS-like components — showing the pattern attackers favor (trigger discovery → force LDAP client behavior → send crafted referral → crash LSASS). Those prior cases are an instructive roadmap for defenders and explain why Microsoft’s LSASS advisories get high operational priority.
- The U.S. CISA and other national bodies listed LSASS/LSA problems among the prioritized vulnerabilities around Microsoft’s June 2025 Patch Tuesday, which underscores how quickly these kinds of kernel/service issues attract attention and weaponization risk.
Q: Do attackers need to be on my internal network to exploit this?
A: Microsoft’s description says an “authorized attacker” can cause the denial of service over network, which usually implies the attacker needs some form of access or authenticated capability. But “authorized” can be satisfied in real life by compromised credentials, insider threat, misconfigured forwarding, or manipulation of DNS/CLDAP flows — so don’t assume remote Internet exposure is the only path.
Q: Is there public PoC exploit code?
A: At the time of writing (August 12, 2025) Microsoft’s Security Update Guide lists the vulnerability entry; public PoCs sometimes follow vendor disclosure — check MSRC and vendor advisories and your threat intel feeds for proof-of-concept code. If you have external threat intelligence or an internal hunting team, treat public PoCs as an escalation trigger to accelerate patching.
Q: Can we mitigate without patching?
A: Yes — short-term mitigations (isolation of DCs from untrusted networks, firewalling outbound CLDAP/LDAP to untrusted hosts, tightening DNS resolution and forwarders, ensuring EDR detection for LSASS crashes) help reduce exploitation windows until you can patch. But these are compensating controls, not permanent fixes.
Reporting and disclosure
- If you detect evidence of exploitation, follow your incident response plan and report to relevant authorities (internal SOC, national CERT/CISA if applicable). Preserve forensic artifacts and coordinate with Microsoft if you believe exploitation involves zero-day or in-the-wild active attacks.
CVE-2025-53716 is a classic, impactful service-level memory bug: a null pointer dereference in LSASS that authorized attackers can weaponize to crash authentication services. While the requirement for authorization narrows some attack paths, the potential operational impact (domain-wide authentication failures, DC reboots, downtime) makes this a high-priority item. The practical, immediate steps are straightforward and urgent: identify affected SKUs from Microsoft’s advisory, patch Domain Controllers and other identity servers first, block or lock down CLDAP/LDAP discovery flows to untrusted networks, and tune detection for lsass.exe crashes and anomalous discovery traffic.
Useful references (authoritative)
- Microsoft Security Update Guide — CVE-2025-53716 (vendor advisory).
- NVD/CISA and public Patch-Tuesday summaries (context on LSASS/LSA issues and related CVEs). (nvd.nist.gov, cisa.gov)
- Community research and write‑ups on LDAP/CLDAP referral abuse and LSASS crashes (historical context and technical walk-throughs).
- I can produce a one‑page emergency runbook you can drop into your SOC playbook (prioritized checklist, commands for inventory and patch-scan, recommended firewall rules for CLDAP/LDAP, EDR detection queries).
- If you give me your Windows Server versions and whether you host Domain Controllers on-premises or in cloud IaaS, I can highlight exactly which KBs you should prioritize (and give a suggested patch order).
Source: MSRC Security Update Guide - Microsoft Security Response Center