CVE-2022-30190 is a support diagnostic tool (MSDT) remote code execution vulnerability in Microsoft Windows. CISA added it to the Known Exploited Vulnerabilities catalogue on 14 June 2022, which means attackers have used it in real attacks. A remote code execution vulnerability exists when MSDT is called using the URL protocol from a calling application such as Word.
How CVE-2022-30190 Works
CVE-2022-30190 is dangerous because it turns a trusted Windows support component into a code execution path. The vulnerability is triggered when MSDT is invoked through the URL protocol from another application, so the attacker does not need to start from the diagnostic tool itself.
That design matters because the exploit chain begins in ordinary user workflows, often through document handling or application launch behaviour. Once a user opens the crafted content, the attack can pivot from a routine document action into arbitrary code execution on the endpoint.
Why This Vulnerability Is Dangerous
Remote code execution in a widely deployed Windows component creates high leverage for attackers. It can be used for initial compromise, payload staging, hands-on-keyboard activity, and follow-on movement inside an environment.
The danger is amplified by the trust placed in built-in tooling and by the fact that exploitation can ride on normal application relationships rather than noisy network behaviour. For background on how vulnerability records and exploitability details are tracked, consult the CVE Program and the NIST National Vulnerability Database.
Exposure, Detection, and Remediation
Organisations should treat this as an asset-scope and exposure question as much as a patching question. The first step is confirming where Windows endpoints, Office workflows, and internet-facing user systems could still invoke the affected call path, then checking vendor guidance and authoritative vulnerability records for current remediation detail.
Defensive review should include endpoint telemetry, script and process creation visibility, and searches for unusual child processes launched from document-centric activity. If patching is delayed, compensating controls such as reducing exposure to untrusted documents, tightening macro and script execution policy, and limiting the reach of vulnerable endpoints can lower risk while remediation is underway.
After patching, organisations should still review for pre-patch compromise because exploitation may have occurred before the fix was deployed. A useful operational reference for this kind of response is the Vulnerability Management Guide.
Identity and Session Impact After Exploitation
When this vulnerability is exploited, the main concern is often not the vulnerability itself but what the attacker can do next with the endpoint. Sessions, browser state, cached credentials, tokens, and other identity-bearing material may be exposed once code execution is achieved.
That means post-incident response should look beyond the vulnerable host and review whether any active sessions, service credentials, or other secret material was reachable from the compromised user context. In practice, the security team should assume the attacker may have moved from execution to credential theft, persistence, or lateral movement if the endpoint was used for privileged work.
For a broader pattern of how attackers turn exploitation into credential access and lateral movement, see The State of NHI & AI Agent Breach Report 2026.
Risk and Threat Considerations
This vulnerability is risky because it gives attackers a reliable path from ordinary user interaction to full code execution on a Windows system. That makes it attractive for phishing, drive-by delivery, and post-compromise expansion into the wider environment.
Failure mechanism: An attacker supplies content or a link path that causes a calling application to launch MSDT through the URL protocol, which then executes attacker-controlled code in the user’s context.
Impact: The result can be endpoint compromise, payload delivery, theft of sensitive material, and a foothold for broader intrusion activity across the network.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5 and CIS Controls v8 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | CVE remediation depends on timely flaw correction and verification. |
| SI-4 — System Monitoring | Detection of exploitation depends on monitoring suspicious execution from user activity. | |
| IR-4 — Incident Handling | Post-patch review and compromise validation are core incident-response actions after exploitation. | |
| Recommendation — Track this CVE under SI-2 and verify affected systems are remediated promptly. Use SI-4 to hunt for abnormal process chains and payload execution from document workflows. Apply IR-4 to investigate possible pre-patch compromise and contain affected endpoints. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | This term is a live vulnerability requiring asset scoping, prioritisation, and remediation tracking. |
| CIS-8 — Audit Log Management | Detection and post-exploitation review rely on endpoint and execution logs. | |
| Recommendation — Prioritise this CVE through CIS-7 and confirm remediation across exposed assets. Use CIS-8 to preserve and review logs for signs of exploitation. | ||
Practitioner Guidance
Why practitioners should care: Treat this as both a vulnerability-management issue and an incident-response issue. Once a platform component becomes a public exploitation path, the operational question is not only whether the fix is available, but whether the environment has already been touched.
What to watch for: Look for suspicious child processes spawned from document workflows, unusual command-line activity, and any evidence that the affected endpoint handled untrusted content before patching.
Practitioner takeaway: Remediation should be paired with compromise review, because patching closes the door only going forward, not for activity that already occurred.
Related resources from NHI Mgmt Group
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.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org