Join our Newsletter — 33% off our NHI Course
Home› FAQ› Cyber Security› Is CVE-2018-8373 (Microsoft Scripting Engine Memory Corruption) being…
Cyber Security

Is CVE-2018-8373 (Microsoft Scripting Engine Memory Corruption) being exploited in the wild?

← Back to all FAQ
By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Cyber Security

Yes. CISA added CVE-2018-8373 to its Known Exploited Vulnerabilities catalogue on 25 March 2022, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. A remote code execution vulnerability exists in the way that the scripting engine handles objects in memory in Internet Explorer.

What “exploited in the wild” means for this CVE

For a CVE like this, “exploited in the wild” is the practical signal that matters most: it means real attackers are already using the flaw, not just proving it in a lab. CISA’s KEV listing is the fastest way to confirm that status, and it is the right place to start when deciding whether this is a watchlist item or an active response item.

That distinction changes prioritisation immediately. Once a vulnerability appears in KEV, the question is no longer whether it is theoretically dangerous, but whether your environment is exposed enough for exploitation to matter now.

For general verification and triage discipline, use the Vulnerability Management Guide to frame the issue as an asset-scope and prioritisation problem, not a standalone CVE lookup.

How to confirm exposure and reduce blast radius

The first operational step is to confirm whether any systems actually run the affected Internet Explorer scripting engine path, including legacy desktop builds, embedded browsers, or other environments where IE components may still be present. In practice, teams often miss this because the vulnerable component is not treated as a separate application owner’s problem.

If the vulnerable software is present, treat the issue as a browser and endpoint exposure problem as much as a patching problem. Browser hardening, isolation, extension control, and strict policy enforcement all reduce the number of paths an attacker can use once a scripting-engine flaw is reachable.

The Enterprise Browser and Browser Security Guide is useful here because it connects browser policy decisions to credential theft, isolation, and extension risk in the same operational view.

Authoritative product and status details should come from the vendor advisory and the CISA Known Exploited Vulnerabilities Catalog, not from secondary summaries.

What to do if patching has to wait

When patching cannot happen immediately, the goal is to shrink exploitability, not to hope the attack wave passes. Disable or restrict unnecessary browser exposure, reduce user interaction with untrusted content, and apply compensating controls that make exploitation harder to reach from routine browsing or document-handling paths.

Teams should also assume that an exploited browser or scripting flaw can be an entry point rather than the end of the incident. That means watching for unusual process launches, suspicious child processes spawned by the browser, and follow-on activity that suggests code execution or persistence.

The Zero-Day and Exploited Vulnerabilities Guide is the best match for the response pattern here because it focuses on KEV-driven triage, emergency mitigation, and post-patch hunting.

The CVE Program is the canonical reference for the vulnerability record itself, while the NIST National Vulnerability Database helps with record context and downstream vulnerability management workflows.

Risk and Threat Considerations

This flaw is risky because a scripting-engine memory corruption issue can provide a direct remote code execution path in a component that is often reachable through normal user activity. When a browser-adjacent flaw is actively exploited, the attacker’s objective is usually initial foothold, followed by execution on the endpoint and then privilege gain or lateral movement.

Failure mechanism: The vulnerability allows malformed content or interaction to drive memory corruption inside the scripting engine, which can be converted into code execution when an attacker can deliver the right trigger path.

Impact: Successful exploitation can lead to endpoint compromise, credential theft, and downstream access to other internal systems if the browser session or the host has useful trust relationships.

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.

FrameworkControl / ReferenceRelevance
CIS Controls v8CIS-7 — Continuous Vulnerability ManagementThe question is about an actively exploited CVE and response prioritisation.
Recommendation — Prioritise remediation for KEV-listed vulnerabilities and verify exposure across all in-scope assets.
NIST SP 800-53 Rev 5SI-2 — Flaw RemediationActively exploited software flaws require controlled remediation and tracking.
RA-5 — Vulnerability Monitoring and ScanningConfirming exposure and tracking affected systems is central to exploiting-in-the-wild triage.
Recommendation — Apply SI-2 to identify, prioritize, and remediate the vulnerable component promptly. Use RA-5 to locate affected hosts and validate whether the vulnerable component is present.
NIST CSF 2.0ID.RA-01 — Asset vulnerabilities are identified and recordedThe answer depends on identifying and tracking exposure to the exploited CVE.
PR.IR-01 — Networks, systems, devices, environments, and data are protected by resilience mechanismsCompensating controls and blast-radius reduction are the practical response when patching waits.
Recommendation — Record the vulnerable asset population and tie the CVE to your risk register. Apply compensating protections that reduce exploit reach while remediation is in progress.

Practitioner Guidance

What to verify: Confirm whether IE or IE-mode dependencies still exist anywhere in the estate, because “modern browser” assumptions often miss legacy rendering paths that remain reachable through enterprise software or policy exceptions.

Decision rule: If the host is exposed and the vulnerable component is present, treat this as a high-priority remediation item even if you have not observed abuse locally, because KEV listing means exploitation is already credible in the wild.

What to measure: Track not just patch completion, but the number of systems where browser hardening, application control, and user-surface reduction materially reduce the chance that a browser memory corruption flaw becomes an endpoint compromise.

Practitioner takeaway: For a KEV-listed browser exploit, the right question is not “is this technically interesting?”, it is “where can this still be reached, and what stops a successful browser exploit from becoming a broader incident?”

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