Is CVE-2022-41128 (Microsoft Windows Scripting Languages Remote Code Execution) being exploited in the wild?

Yes. CISA added CVE-2022-41128 to its Known Exploited Vulnerabilities catalogue on 8 November 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Microsoft Windows contains an unspecified vulnerability in the JScript9 scripting language which allows for remote code execution. Any organisation running the affected product should treat remediation as urgent.

What “exploited in the wild” means for this CVE

For a CVE like this, “being exploited in the wild” means the issue is not just theoretical, proof-of-concept, or low-confidence chatter. CISA’s KEV catalogue is the practical indicator that matters here, because inclusion reflects reliable evidence of active exploitation and turns the question from “could this be abused?” into “treat this as an urgent exposure.”

The immediate operational question is whether you run the affected Windows Scripting Languages component anywhere in your environment, especially on endpoints or servers that can receive untrusted files, scripts, or content. If the vulnerable scripting language is present, the attack surface is real even when exploitation is not yet visible in your own telemetry.

For broader prioritisation, use an actively exploited-vulnerability workflow rather than a generic patch queue. NHIMG’s Zero-Day and Exploited Vulnerabilities Guide is the right operational lens here because KEV-listed issues need faster triage, tighter exception handling, and follow-up validation after remediation.

Why the JScript9 flaw is operationally serious

This is a remote code execution issue, so successful exploitation can move from initial touch to arbitrary code execution on the target host. That makes the consequence materially different from a simple crash, information disclosure, or nuisance bug, because code execution can be used to establish persistence, drop additional payloads, or pivot into adjacent systems.

The fact that Microsoft Windows is the affected product also matters for scale. Windows scripting components are often present in mixed-use environments, which means a single unpatched exposure can exist across user workstations, admin workstations, and servers that are not all monitored with the same intensity.

In practice, this kind of weakness is often paired with delivery methods that look mundane, such as opening crafted content, loading a malicious script, or triggering the component through a trusted workflow. That is why exploited RCE flaws tend to produce disproportionate impact relative to their initial entry path.

How to verify exposure and reduce blast radius

Start by confirming whether the vulnerable scripting language is installed and reachable in the environments that matter most, then identify where untrusted content can reach those systems. The highest-risk systems are usually those with broad user interaction, administrative privileges, or access to sensitive internal resources.

Prioritise internet-facing or externally reachable Windows systems first.
Check whether high-value hosts can execute scripts, open web content, or process files from less-trusted sources.
Review whether application control, attack surface reduction, or script restrictions are already limiting executable paths.
Validate that detection coverage exists for suspicious script execution, child process spawning, and unusual post-exploitation behaviour.

If you cannot remediate immediately, reduce exposure by restricting script execution paths, tightening application control, and isolating the most exposed hosts. That will not remove the flaw, but it can narrow the set of conditions an attacker needs.

Risk and Threat Considerations

The main risk is not just exploitation of the vulnerable component itself, but the downstream use of remote code execution as an initial foothold. Once an attacker can run code, the issue becomes a broader host compromise problem, including credential access, lateral movement, and secondary payload delivery.

Failure mechanism: A crafted input or delivery path triggers the vulnerable JScript9 handling logic, and the attacker gains code execution in the context of the affected process or user.

Impact: The host can be turned into an execution point for further intrusion, data theft, persistence, or internal pivoting, which is why KEV-listed RCE issues should be treated as urgent even before local evidence of compromise is found.

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 SP 800-53 Rev 5 and NIST CSF 2.0 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 rapid vuln prioritization and remediation central.
Recommendation — Prioritise and remediate KEV-listed vulnerabilities first.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	This CVE requires urgent flaw remediation and exposure validation.
	RA-5 — Vulnerability Monitoring and Scanning	Confirm where the vulnerable Windows component exists and where exposure remains.
Recommendation — Patch or mitigate the flaw and verify remediation promptly. Scan the estate to confirm exposure and track remediation status.
NIST CSF 2.0	ID.RA-01 — Asset Vulnerability and Exposure Identification	Knowing where the vulnerable product exists is prerequisite to response.
	PR.IP-12 — Vulnerability Management	The question hinges on urgent response to an actively exploited vulnerability.
Recommendation — Identify affected assets and rank them by exposure and business impact. Use a formal vulnerability management process to drive urgent remediation.

Practitioner Guidance

What to prioritise: Treat KEV inclusion as the trigger for immediate exposure validation, not as a backlog item. If the vulnerable component exists on high-value or high-reach hosts, those systems should move to the front of the remediation queue.

What to verify: Confirm not only whether the patch or mitigation is applied, but also whether any suspicious script execution, unexpected child processes, or new persistence mechanisms appeared before remediation. If you only check patch state, you may miss prior compromise.

Decision rule: If you cannot patch at once, compensate by constraining execution paths and increasing monitoring on the affected Windows estate. If the host already handled untrusted content during the exposure window, treat it as a compromise-assessment candidate, not just a patch candidate.

Practitioner takeaway: For actively exploited RCE flaws, the correct question is not whether exploitation is possible, but whether the environment has already been exposed long enough for exploitation to be practical.