Yes. CISA added CVE-2021-27085 to its Known Exploited Vulnerabilities catalogue on 3 November 2021, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Microsoft Internet Explorer contains an unspecified vulnerability that allows for remote code execution. Any organisation running the affected product should treat remediation as urgent.
How CISA’s KEV listing answers the exploitation question
CISA’s KEV catalogue is the key signal here because it is reserved for vulnerabilities with evidence of active exploitation. For practitioners, that means the question is not whether exploitation is possible in theory, but whether the flaw should be treated as already being used against real targets. The operational response should follow that assumption until exposure is ruled out.
Because CISA placed this issue into KEV, treat it as a live prioritisation problem, not a routine patch queue item. Even when an exploit path is not fully documented in public reporting, KEV status changes the decision threshold: verify whether Internet Explorer is present anywhere in your estate, including legacy endpoints, virtual desktops, and systems where it may still be enabled for compatibility.
Where Internet Explorer remains installed or enabled, confirm whether the affected host is still reachable by users, scripts, or automation. Legacy browser components often persist inside larger desktop images, and that makes inventory accuracy more important than assumptions based on default browser settings alone.
What the vulnerability means for exposure and remediation
This is a remote code execution issue in Microsoft Internet Explorer, so the main exposure is loss of control over the endpoint after a successful exploit. The practical concern is that browser exploitation can become the first step in broader compromise, especially when users browse untrusted content or inherit legacy browser settings from older enterprise builds.
Zero-Day and Exploited Vulnerabilities Guide is relevant here because KEV-listed issues demand the same kind of emergency triage, verification, and post-remediation checking used for actively exploited flaws. Use the vendor advisory and the CISA KEV entry to confirm the exact mitigation path for your environment, rather than relying on secondary summaries.
When remediation is delayed, reduce exposure by removing browser access paths that are not essential, tightening user execution rights, and monitoring for suspicious browser-triggered process launches. If the vulnerable component is still present for compatibility reasons, assume that any internet-facing or user-driven execution path may be abused before the next maintenance window.
What to check for compromise before and after fixing it
Because KEV status implies real-world abuse, a fix alone is not enough if you have not checked whether the exploit already landed. Review endpoint telemetry, browser history, script execution, child processes, downloaded files, and any anomalous persistence that appeared around the time the issue became public or was first observed in your environment.
Vulnerability Management Guide fits this question because it covers the practical sequence of scope, prioritisation, verification, and exception handling that should follow an exploited vulnerability finding. Use it to structure your internal response so patching, exposure validation, and remediation evidence are handled together instead of as separate tasks.
If you find signs of execution, treat the system as potentially compromised even if the browser patch is later applied. That may require credential review, session invalidation, and broader hunting on adjacent endpoints that share the same image, user profile, or browsing configuration.
Risk and Threat Considerations
This vulnerability matters because browser RCE can turn ordinary web access into code execution on a user endpoint. In a legacy browser context, the attacker only needs one successful interaction path, which makes exposed systems attractive wherever Internet Explorer remains reachable for compatibility or embedded use.
Failure mechanism: A malicious page or content path triggers the Internet Explorer flaw, code runs with the victim’s user context, and the attacker can pivot to persistence, credential theft, or follow-on payload delivery.
Impact: The likely outcome is endpoint compromise, with possible downstream access to internal resources, saved credentials, and additional systems reachable from the same user session or device.
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 | KEV-listed browser RCE needs rapid identification and remediation of exposed assets. |
| Recommendation — Prioritise the IE flaw as an exploited vulnerability and verify remediation on every exposed endpoint. | ||
| NIST CSF 2.0 | ID.RA-01 — Asset vulnerabilities are identified and documented | The question hinges on confirming exposure to an actively exploited vulnerability. |
| PR.PS-01 — Configurations are managed consistent with risk and security policies | Mitigation depends on disabling or removing the vulnerable browser component where possible. | |
| DE.CM-01 — Networks and network services are monitored to find potentially adverse events | Confirmed exploitation requires hunting for browser-triggered suspicious activity and compromise signs. | |
| Recommendation — Identify every system that still exposes Internet Explorer and document the risk. Harden endpoints so Internet Explorer is disabled or removed where it is not required. Monitor affected hosts for suspicious child processes, persistence, and post-exploit behavior. | ||
| NIST SP 800-53 Rev 5 | RA-5 — Vulnerability Monitoring and Scanning | Actively exploited flaws require continuous scanning and validation of exposure. |
| Recommendation — Scan for Internet Explorer exposure and track remediation until the vulnerable component is gone. | ||
Practitioner Guidance
What to prioritise: First confirm whether Internet Explorer is still present, enabled, or callable anywhere in your estate, then treat any reachable instance as urgent until patched or removed. If you have multiple legacy desktop images, prioritise those that serve high-privilege users or broad user populations.
What to verify: Validate both the vendor remediation status and the host-level outcome. A successful patch campaign should be accompanied by evidence that the vulnerable component is disabled or no longer accessible, not just that an update job was run.
Decision rule: If you cannot patch immediately, shorten the exposure window by removing access paths, increasing monitoring on affected endpoints, and preparing a compromise-assessment workflow. Do not wait for confirmed exploitation before escalating the issue operationally.
Practitioner takeaway: For KEV-listed browser flaws, the right question is not whether exploitation is conceivable, but whether you have already reduced the attack surface and checked for signs that someone else found it first.
Related resources from NHI Mgmt Group
- Guide: Enterprise Browser and Browser Security Guide
- Is CVE-2013-1347 (Microsoft Internet Explorer Remote Code Execution) being exploited in the wild?
- Is CVE-2017-0222 (Microsoft Internet Explorer Remote Code Execution) being exploited in the wild?
- CVE-2021-27085 (Microsoft Internet Explorer Remote Code Execution)
- Is CVE-2021-1647 (Microsoft Defender Remote Code Execution) being exploited in the wild?