Is CVE-2025-24054 (Microsoft Windows NTLM Hash Disclosure Spoofing) being exploited in the wild?

Yes. CISA added CVE-2025-24054 to its Known Exploited Vulnerabilities catalogue on 17 April 2025, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Microsoft Windows NTLM contains an external control of file name or path vulnerability that allows an unauthorized attacker to perform spoofing over a network.

What this means for validation and triage

CISA’s KEV listing is the practical signal that this is not a theoretical issue. For defenders, the first question is not whether the CVE exists, but whether Windows assets in your environment can still be reached in a way that would allow ntlm hash disclosure spoofing, including legacy systems, user workstations, and any endpoint that can process untrusted network content.

Because the vulnerability involves spoofing over the network, triage should focus on exposed Windows hosts, recent authentication anomalies, and any environment segment where NTLM is still accepted or heavily relied on. If you are already running a vulnerability management process, treat this as a validation and exposure question, not just a patch queue item. Use the CISA Known Exploited Vulnerabilities Catalog to confirm the KEV status and prioritise affected assets.

For broader remediation workflow, align the triage with the Vulnerability Management Guide so exposure, exception handling, and verification are handled as one process rather than separate tickets.

How to respond when patching cannot happen immediately

If you cannot patch straight away, the goal is to reduce reachable attack surface and narrow the conditions in which NTLM-based spoofing can succeed. That usually means limiting where NTLM is accepted, tightening segmentation around Windows systems that process file or path content, and temporarily raising scrutiny on remote access, file shares, and other network paths that can deliver the trigger condition.

Any delay should be treated as a short exception with explicit owner, expiry, and compensating controls. The point is not to accept the risk indefinitely, but to make the unpatched window smaller, more visible, and more constrained.

Use vendor guidance for the exact fix and any compatible mitigations, and track the asset set separately from general Windows patching so the vulnerable population does not get lost in routine maintenance work.

What to check for signs of earlier compromise

With KEV-listed flaws, assume that exploitation may have started before remediation. For this issue, validate whether affected systems show unusual NTLM activity, unexpected outbound connections, suspicious file interactions, or authentication events that do not fit the normal user or service pattern.

It is also worth reviewing whether privileged or reusable credentials could have been exposed through the spoofing path. If the flaw sits in a place where hashes, sessions, or downstream authentication material could be captured or relayed, you should check whether the attacker could have moved beyond the initial spoofing step into lateral movement or persistence.

For confirmation work, correlate endpoint telemetry, authentication logs, and network logs rather than relying on a single control plane. A clean vulnerability scan does not prove there was no prior abuse, only that the current exposure may now be lower.

Risk and Threat Considerations

The main risk is credential exposure in an environment that still trusts NTLM enough for an attacker to turn a spoofing flaw into usable authentication material. Once that material is exposed or replayable, the issue can shift from a single host problem to broader account and session risk.

Failure mechanism: An attacker abuses the network-triggered spoofing condition to influence how Windows handles file or path content, then leverages the resulting NTLM disclosure or relay opportunity to gain additional access.

Impact: The practical outcome can include unauthorized access, credential reuse, lateral movement, and a longer incident window if defenders only focus on the original CVE rather than the authentication consequences.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	ID.RA-01 — Asset Vulnerability Identification	The question is about exploited vulnerability triage and exposure confirmation.
Recommendation — Identify vulnerable Windows assets and prioritise remediation using confirmed exploitation status.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV-listed exploitation demands prioritised vulnerability handling and verification.
Recommendation — Track, prioritise, and verify remediation for KEV-listed systems before routine backlog items.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	Validating exposure and confirming remediation depend on vulnerability scanning and monitoring.
	IA-5 — Authenticator Management	NTLM hash disclosure directly implicates credential material and authentication handling.
	AC-17 — Remote Access	The issue is exploitable over the network and may require remote access constraint.
Recommendation — Scan for exposed Windows assets and verify the vulnerable condition is removed. Rotate or invalidate exposed authentication material when compromise is plausible. Restrict remote paths that can trigger or relay the vulnerable Windows interaction.

Practitioner Guidance

What to prioritise: Focus first on internet-exposed or high-trust Windows systems, then on any segment where NTLM remains enabled for operational reasons. Those are the places where a confirmed exploited vulnerability is most likely to matter operationally, even if the patch backlog is large.

What to verify: Confirm that you can identify all hosts using NTLM, not just the hosts with the CVE flagged. The weak point is often the combination of vulnerable software plus an authentication path that was never removed or restricted.

Decision rule: If an affected system also handles privileged logons, file access from less-trusted networks, or service accounts with broad reach, treat the remediation as higher urgency than a normal workstation patch.

Practitioner takeaway: For a KEV-listed Windows flaw, the real objective is to prove whether the vulnerable path can still lead to trust abuse, then close that path before assuming patching alone has eliminated risk.