Is CVE-2022-26925 (Microsoft Windows LSA Spoofing) being exploited in the wild?

Yes. CISA added CVE-2022-26925 to its Known Exploited Vulnerabilities catalogue on 1 July 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Microsoft Windows Local Security Authority (LSA) contains a spoofing vulnerability where an attacker can coerce the domain controller to authenticate to the attacker using NTLM.

How to verify active exploitation of CVE-2022-26925

For an exploited vulnerability question, the first task is not to debate the exploit path, but to confirm whether your environment is exposed and whether the vulnerability is already being used by others as a real-world attack path. CISA’s KEV catalogue is the best starting point for triage, and the vendor advisory should be used for the exact remediation details for your Windows estate.

Because this issue is about microsoft windows lsa spoofing, verification should focus on domain controllers and any systems that can participate in the authentication flow an attacker would try to influence. If the vulnerable authentication path exists in your environment, treat it as a priority exposure rather than a theoretical bug.

When you are checking exposure, use a vulnerability-management workflow that distinguishes between “present in inventory” and “present in a condition an attacker can actually use.” A domain controller with the vulnerable LSA behaviour and reachable NTLM-based trust relationships has a materially different risk profile from a host that merely runs the same Windows family.

What the spoofing flaw changes in practice

This vulnerability matters because it can let an attacker coerce the domain controller into authenticating to the attacker, which turns a spoofing weakness into an authentication-abuse path. That is why active exploitation evidence is more important here than a generic severity label: the practical question is whether an attacker can use the trust relationship to obtain usable credentials or relayable authentication material.

In operational terms, this is not just a patching item. It is also an identity-trust issue, because the attack path depends on how Windows systems, domain controllers and NTLM-based authentication interact. If the trust boundary is reachable, the flaw can become a foothold for lateral movement or further credential abuse.

For readers maintaining inventory and prioritisation processes, Zero-Day and Exploited Vulnerabilities Guide is useful because it frames KEV-listed issues around emergency triage, compromise assessment and post-patch hunting. If you are mapping this vulnerability into a broader programme, Vulnerability Management Guide covers the prioritisation logic that should drive response on exploited CVEs.

How to respond when patching must wait

If you cannot remediate immediately, the practical objective is to reduce the attacker’s ability to trigger or exploit the authentication behaviour while you narrow the blast radius. That usually means tightening exposure around domain controllers, reviewing NTLM usage, and limiting which systems can initiate the relevant trust flow.

Where the attack path may already have been used, do not stop at patch status. Check for signs of authentication abuse, unusual domain controller outbound activity, suspicious NTLM traffic, and any evidence that accounts or systems were coerced into authenticating unexpectedly. If the flaw was reachable, assume the attacker may have tried to turn that coercion into credential relay or privileged access.

CISA Known Exploited Vulnerabilities Catalog should be your external reference for whether the issue remains operationally relevant, while NIST National Vulnerability Database and the CVE Program help anchor the record and terminology you use in tracking.

Risk and Threat Considerations

This vulnerability is risky because spoofing on a domain controller can turn a single authentication weakness into a broader identity compromise path. If an attacker can coerce authentication from a trusted system, the exposure is not limited to that one host, it can become a stepping stone into privileged authentication flows and lateral movement.

Failure mechanism: The attacker abuses the LSA spoofing condition to make the domain controller authenticate outward, then tries to leverage the resulting trust relationship, relayed authentication, or captured challenge-response material for further access.

Impact: Successful abuse can expose high-value authentication paths, enable privilege escalation or lateral movement, and force incident response teams to investigate whether the authentication boundary was already crossed before remediation.

Standards & Framework Alignment

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

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

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-4 — Secure Configuration of Enterprise Assets and Software	Exploited Windows flaws require hardened configurations to reduce reachable attack paths.
	CIS-7 — Continuous Vulnerability Management	KEV-listed exploitation depends on fast identification and remediation of vulnerable assets.
Recommendation — Harden domain controller settings and disable unnecessary authentication pathways that expose the flaw. Prioritise and remediate KEV-listed Windows vulnerabilities on exposed systems first.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	This CVE demands timely remediation and exception tracking for exploited software flaws.
	IA-5 — Authenticator Management	The attack path abuses authentication material and trust relationships.
	AC-17 — Remote Access	Spoofing and authentication coercion are materially affected by remote-access exposure.
Recommendation — Track the flaw through remediation, exception, and verification until exposure is removed. Rotate or invalidate affected authentication material if the flaw may have enabled abuse. Restrict remote paths that let an attacker trigger or relay the vulnerable authentication flow.

Practitioner Guidance

What to prioritise: Put this at the front of the queue if the affected systems include domain controllers, NTLM is still broadly enabled, or the environment has a history of authentication relay risk. In those cases, patching and exposure reduction should happen before lower-value remediation work.

What to verify: Confirm whether any domain controller or adjacent Windows infrastructure can still participate in the vulnerable authentication sequence, and verify whether compensating controls actually break the attacker’s coercion path. A control that exists on paper but does not interrupt the trust flow is not enough.

Practitioner takeaway: For KEV-listed spoofing flaws, the real decision is not whether the CVE exists, but whether the trust path is still reachable and could have already been abused, because that determines whether you are doing routine patching or compromise-focused response.