Is CVE-2019-1367 (Microsoft Internet Explorer Scripting Engine Memory Corruption) being exploited in the wild?

Yes. CISA added CVE-2019-1367 to its Known Exploited Vulnerabilities catalogue on 3 November 2021, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. Microsoft Internet Explorer contains a memory corruption vulnerability in how the scripting engine handles objects in memory. Any organisation running the affected product should treat remediation as urgent.

What CISA Listing Means for This CVE

This question is not really about the vulnerability name alone, it is about whether the vulnerability has moved from theoretical exposure to active exploitation risk. For CVE-2019-1367, the operational meaning is that defenders should treat affected Internet Explorer environments as exposed to real-world attack, not just patch backlog noise. CISA’s KEV listing is the practical signal that remediation should be prioritised over routine scheduling.

Because the flaw is a scripting engine memory corruption issue, the immediate concern is not only that a browser can crash, but that malformed content can trigger code execution paths or destabilise the browser process in ways attackers can chain with delivery or privilege escalation. The right response is to assume the vulnerable product may be a viable entry point until exposure is removed or the product is otherwise contained.

If you need a quick verification path, confirm whether Internet Explorer is still enabled anywhere in the estate, including legacy line-of-business systems, embedded browser components, compatibility modes and unmanaged endpoints. For a vulnerability that is already known to be exploited, the first question is where it still exists, not whether users still prefer it.

How to Respond When You Find Exposure

Start by removing or reducing exposure to the affected browser component wherever that is feasible, then follow vendor remediation guidance for the exact platform and build in use. For active exploitation cases, remediation should be treated as urgent because delay increases the chance that the same flaw is being used opportunistically or as part of a broader intrusion chain.

If patching or hard removal must wait, use compensating controls that reduce browser attack surface and make exploitation harder to reach. That usually means constraining who can launch the affected browser, limiting access to untrusted content, tightening web filtering and reducing the number of systems that can still render legacy Internet Explorer content.

Review whether the vulnerable component is still required for any business process. In many estates the real issue is dependency, not user demand: one legacy application keeps the browser alive long after the broader environment has moved on. If that is the case, remediation planning should include application migration, not just endpoint patching.

What to Check After Remediation

For a KEV-listed vulnerability, remediation is only half the job. Check for signs that the environment was already touched before the fix, especially if the vulnerable browser was exposed to internet-facing or email-borne content. Browser exploitation often leaves limited direct evidence, so the investigation should look for unusual process launches, suspicious downloads, unexpected child processes and signs of follow-on credential theft or lateral movement.

Use the opportunity to validate whether any supporting controls need adjustment, such as application allowlisting, browser restriction policy, endpoint detection coverage and user separation between routine browsing and privileged work. When a browser flaw is actively exploited, the control failure is often not just the flaw itself, but the fact that the browser was allowed to remain a universal execution surface.

Risk and Threat Considerations

Actively exploited browser flaws are attractive because they provide a high-volume delivery path into endpoints and can be triggered through ordinary user activity. The risk is amplified when a legacy browser remains available alongside modern controls, since attackers only need one reachable path to reach the vulnerable engine.

Failure mechanism: Memory corruption in the scripting engine can let attacker-controlled content drive execution in an unsafe way, especially when the browser remains enabled for legacy compatibility or mixed-trust browsing.

Impact: The result can be endpoint compromise, follow-on payload delivery, credential exposure and a larger intrusion path than the browser issue itself suggests.

Standards & Framework Alignment

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

MITRE ATT&CK addresses the attack and risk surface, while NIST SP 800-53 Rev 5, CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	Active exploitation makes timely flaw remediation central to this browser vulnerability.
Recommendation — Prioritise and verify remediation for the affected browser component before routine patch queues.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV-listed exploitation requires urgent identification and remediation of exposed systems.
Recommendation — Identify exposed endpoints quickly and drive urgent remediation for the vulnerable browser path.
NIST CSF 2.0	ID.RA-01 — Asset Vulnerabilities Are Identified and Managed	The answer depends on finding exposed instances and managing the vulnerability as an active risk.
	PR.PS-03 — Configuration Management Processes Are in Place and Managed	Containing or removing legacy browser capability is a configuration and hardening action.
Recommendation — Inventory affected assets and manage the exposure as a current operational risk. Disable or constrain the legacy browser path through controlled configuration changes.
MITRE ATT&CK	T1190 — Exploit Public-Facing Application	The exploitation context concerns attacker use of a reachable software flaw as an entry path.
Recommendation — Map exposed browser-facing paths to likely initial-access abuse and watch for follow-on activity.

Practitioner Guidance

What to prioritise: Treat this as an exposure-removal task, not a routine vulnerability ticket. Focus first on finding every place where the affected browser still exists, then rank those instances by internet exposure, user privilege and business criticality.

What to verify: Confirm whether the remediation actually removes the attack surface, or merely hides it behind compatibility settings and user workarounds. A fix that leaves the browser available for high-risk browsing does not materially reduce the problem.

Practitioner takeaway: Once a browser vulnerability is in KEV, the key decision is whether you can remove or tightly contain the execution path fast enough to outrun exploitation, not whether the organisation can tolerate another deferred patch cycle.