Is CVE-2022-30190 (Microsoft Windows Support Diagnostic Tool (MSDT) Remote Code Execution) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2022-30190 to its Known Exploited Vulnerabilities catalogue on 14 June 2022, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. A remote code execution vulnerability exists when MSDT is called using the URL protocol from a calling application such as Word.

How to read active exploitation for CVE-2022-30190

CISA’s KEV listing is the practical signal that matters here: it means the vulnerability is not just theoretically dangerous, but has credible evidence of exploitation in the wild. For this CVE, that should shift the question from “is it real?” to “is any Windows endpoint still able to invoke MSDT through a document or URL handler path?”

Because the flaw is triggered when MSDT is called through a URL protocol from a calling application such as Word, exposure is often broader than a single application team expects. A workstation, virtual desktop, or file-sharing workflow can be enough to create reachability if the protocol handler remains available and users can open crafted content.

That is why KEV status and ransomware linkage should drive urgent triage, not just ordinary vulnerability backlog handling. If you are still inventorying, the first pass should be to identify where MSDT remains enabled, where Word or similar document handlers are present, and whether any security tooling already blocks the affected launch path.

See the CISA Known Exploited Vulnerabilities Catalog and the CVE Program when you need the authoritative record for the vulnerability and its exploitation status.

What exposure to confirm before you assume you are safe

The practical exposure check is whether any business process can still hand untrusted content to an application that can invoke MSDT. That includes email attachments, collaboration platforms, document repositories, helpdesk workflows, and any endpoint where a user can be induced to open a malicious file.

Do not limit the review to managed desktops. Remote workers, shared terminals, and contractor devices can all preserve the attack path if they can open content that reaches the vulnerable handler. If the environment still permits that launch path, the issue remains operationally live even if exploitation attempts have not yet been observed internally.

Where patch timing is uncertain, temporarily reducing the launch surface is often more valuable than waiting for perfect inventory. Blocking the protocol handler, constraining document execution pathways, and tightening attachment handling can materially reduce exposure while permanent remediation is staged.

For vulnerability triage and prioritisation, the Vulnerability Management Guide explains how KEV status, exception handling, and verification should shape remediation urgency.

What to do if patching and removal cannot happen immediately

The main decision is whether you can eliminate the trigger path or only reduce it. If you cannot patch or remove the vulnerable component right away, focus on controls that stop the initial delivery method from reaching the affected handler and make exploitation harder to sustain.

That usually means tightening mail and web filtering, restricting script and document behaviors, and validating that endpoint protection is configured to detect the known exploitation pattern rather than just the CVE name. For high-value systems, treat the workaround as temporary and auditable, not as a long-term substitute for remediation.

Where business pressure delays change, set a short exception window and require explicit ownership for the residual risk. The risk is not abstract, because this vulnerability has already been tied to active campaigns and ransomware use, so exception handling should be time-bound and reviewed like an emergency control override.

Use the FIRST EPSS model as a supplemental prioritisation input, but do not let it outrank confirmed exploitation in KEV when deciding what gets attention first.

Risk and Threat Considerations

This vulnerability matters because it gives attackers a reliable way to move from document delivery to code execution on Windows endpoints. Once a user opens the right content, the attacker can gain a foothold without needing a separate software bug in the target application itself.

Failure mechanism: The exploit path abuses the MSDT URL protocol handler from a calling application, so a crafted document can launch code execution through a trusted local workflow instead of a visibly malicious binary.

Impact: Successful exploitation can lead to endpoint compromise, followed by credential theft, lateral movement, and deployment of ransomware or other post-exploitation payloads.

Standards & Framework Alignment

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

CIS Controls v8, NIST CSF 2.0 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-7 — Continuous Vulnerability Management	Active exploitation makes timely identification and remediation central.
Recommendation — Prioritise and track remediation for KEV-listed vulnerabilities first.
NIST CSF 2.0	ID.RA-01 — Asset Vulnerabilities Are Identified and Recorded	This CVE answer depends on confirming exposure and exploitability across assets.
	RS.MA-01 — Mitigation Is Performed	The question is operationally about urgent response to active exploitation.
Recommendation — Identify affected assets and record exposure to the exploited flaw. Execute containment and remediation actions as soon as exploitation is confirmed.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	KEV status requires scanning and monitoring for the vulnerable condition.
	SI-2 — Flaw Remediation	This CVE requires prompt remediation or compensating controls.
Recommendation — Continuously scan for the vulnerable condition and validate remediation. Remediate the flaw promptly or apply documented compensating controls.

Practitioner Guidance

What to prioritise: Prioritise endpoints and user groups that can still open untrusted documents or reach the MSDT launch path, then verify whether security controls actually block that path rather than only detect the CVE by signature.

What to verify: Confirm the vulnerable handler is disabled or otherwise unreachable, and retain evidence that the block works across standard user workflows, not only in a lab test.

Decision rule: If the environment cannot be patched immediately, treat exposure reduction as an emergency measure and keep the exception period short enough that it does not become a standing control failure.

Practitioner takeaway: For a KEV-listed remote code execution flaw, proof of exploitation should drive urgent containment first, because the operational question is not whether the bug exists, but whether any reachable path still lets a user trigger it.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org