Is CVE-2025-30397 (Microsoft Windows Scripting Engine Type Confusion) being exploited in the wild?

Yes. CISA added CVE-2025-30397 to its Known Exploited Vulnerabilities catalogue on 13 May 2025, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Microsoft Windows Scripting Engine contains a type confusion vulnerability that allows an unauthorized attacker to execute code over a network via a specially crafted URL.

What it means for a flaw to be “exploited in the wild”

“Exploited in the wild” means defenders have credible evidence that real attackers are already using the weakness outside a lab or proof-of-concept setting. For this question, the practical answer is not just whether the CVE exists, but whether it has crossed the threshold from theoretical risk to active campaign risk. That changes patch urgency, exposure review, and incident triage.

When CISA places a CVE in the Known Exploited Vulnerabilities catalogue, it is signaling that exploitation is established enough to merit immediate operational attention. For current KEV-listed issues and remediation tracking, CISA Known Exploited Vulnerabilities Catalog is the authoritative source to pair with the vendor advisory.

Because this CVE is a Microsoft Windows scripting engine type confusion issue that enables network-reachable code execution through a crafted URL, the exploitation question is also an exposure question: any internet-facing or user-facing path that can hand the URL to a Windows host deserves immediate review. That is why you should treat the KEV listing as an operational trigger, not just a research note.

How to validate exposure and scope

Start by confirming whether any Windows systems in your environment can reach the affected scripting surface through normal browsing, email, chat, document handling, or embedded-link workflows. The question is not only whether the platform exists, but whether users or automated processes could open attacker-controlled content that reaches the scripting engine.

Review asset inventories for Windows endpoints and servers, then separate externally exposed systems from internal-only hosts. If your environment uses browser-based application flows, legacy intranet content, or any process that can launch URLs from untrusted sources, those paths should be considered higher priority for verification and mitigation.

For the vulnerability record itself, use the official record and supporting vendor guidance rather than secondary write-ups. The canonical sources are the CVE Program and the NIST National Vulnerability Database, which help anchor the identifier, vendor attribution, and record metadata you should be using in internal tracking.

Response priorities when patching or mitigation must wait

If you cannot remediate immediately, reduce exposure first. Limit who can browse untrusted content on exposed Windows systems, tighten egress and browser-launch pathways where feasible, and treat suspicious URL handling as a high-value detection opportunity. The key objective is to shrink the number of opportunities an attacker has to deliver the crafted URL.

Use temporary compensating controls only as a bridge to remediation. That means prioritizing system isolation, restricting risky user populations, and accelerating patch deployment on assets that handle internet content or external communications. If the system cannot be patched promptly, it should be treated as a known exposed path, not a low-priority backlog item.

Zero-Day and Exploited Vulnerabilities Guide is a useful internal reference for prioritizing KEV-listed issues, emergency mitigation, and post-patch verification when exploitation is already active. Its value here is practical: it aligns response timing with the reality of active exploitation, not just with severity labels.

Risk and Threat Considerations

Once a weakness is in KEV, the main risk is not abstract code execution, it is rapid weaponisation against systems that have not yet been patched or hardened. For a scripting-engine flaw reached through a URL, the threat path can be broad because users, embedded links, and automated content flows can all become delivery mechanisms.

Failure mechanism: Attackers abuse the crafted URL path to trigger type confusion in Windows Scripting Engine and execute code on the target host, typically before defenders have completed patching or exposure reduction.

Impact: Successful exploitation can lead to initial code execution, host compromise, follow-on payload delivery, and broader intrusion activity on systems that trust external content.

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 prioritised vulnerability management central here.
Recommendation — Prioritize and remediate KEV-listed systems first, then verify exposure after patching.
NIST CSF 2.0	ID.RA-01 — Asset vulnerabilities are identified and documented	This question is about confirming vulnerable assets under active exploitation.
	RS.MA-1 — Incidents are contained	Active exploitation requires immediate containment when patching is delayed.
Recommendation — Document exposed Windows systems and track them against the active exploitation list. Contain affected hosts and restrict risky access paths until remediation is complete.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	KEV-driven triage depends on identifying vulnerable hosts and confirming exposure.
	SI-2 — Flaw Remediation	The subject is an actively exploited software flaw requiring rapid remediation.
Recommendation — Scan for vulnerable Windows assets and validate remediation after applying fixes. Apply vendor remediation or approved mitigation to exposed systems without delay.

Practitioner Guidance

What to verify: Confirm whether any Windows endpoints or servers still accept untrusted URL-driven code execution paths, then verify patch status on those assets first. In a KEV scenario, “we plan to patch” is not a meaningful control state.

Decision rule: If the asset is internet-facing, user-facing, or handles externally supplied links, treat it as urgent remediation scope. If you must defer, isolate the host and limit exposure until the fix is applied.

Practitioner takeaway: For exploited-in-the-wild flaws, the operational question is speed of containment, not debate over exploitability; the KEV listing means the response clock has already started.