How do you patch or mitigate CVE-2021-27085 (Microsoft Internet Explorer Remote Code Execution)?

CISA’s required action for CVE-2021-27085 is to apply updates per vendor instructions. In practice, find every instance of Microsoft Internet Explorer in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.

What patching means for an Internet Explorer RCE with active exploitation

The right response is not just “install a patch,” but to treat the browser as an exposed execution surface until every instance is confirmed updated or removed. For a flaw like this, the practical security question is whether any endpoint still has Internet Explorer available to launch, reach untrusted content, or provide an attacker with a path to code execution.

Because the direct answer already points to vendor updates and documented mitigations, the operational focus is exposure control. That means inventorying every place IE can still run, checking whether it is enabled through compatibility settings or legacy dependencies, and deciding whether the safest short-term move is isolation or service removal while the vendor fix is rolled out.

When a browser RCE is being used in the wild, patching is only one part of the fix. You also need to assume some endpoints may have been touched before remediation, especially if the browser was used for routine web access, internal portals, or user-driven file handling that could have delivered the exploit.

How to confirm exposure before and after remediation

Start with asset discovery, because incomplete visibility is the most common reason browser vulnerabilities survive a patch cycle. Confirm where Microsoft Internet Explorer is present, whether it is actively enabled, and whether any legacy application still depends on it for access or rendering.

If you cannot remove it immediately, reduce the attack surface first. That usually means blocking internet-facing use, restricting it to the smallest possible set of hosts, and preferring a controlled replacement path over indefinite exception handling. The Enterprise Browser and Browser Security Guide is useful here because the same browser-hardening logic applies when a legacy browser remains in the environment.

After applying the vendor update or mitigation, verify that the vulnerable browser is no longer reachable in the way attackers expect. In practice, that means checking endpoints, remote access paths, and legacy application workflows rather than trusting a single compliance report or a partial scan.

What to do if you cannot patch immediately

If patching must wait, the most defensible mitigation is to remove the vulnerable component from internet exposure and, where possible, take it out of service. That is a containment decision, not a convenience decision, because a remotely exploitable browser flaw gives attackers a direct route from content to code execution.

Use the delay to narrow trust. Limit who can open the browser, where it can connect, and what content it can process. If a business function still depends on IE, isolate that function from normal browsing and treat the workflow as a high-risk exception until the update is deployed.

For remediation planning and prioritisation, the Vulnerability Management Guide is the right internal reference because this kind of issue needs asset scope, prioritisation, exception handling, and verification rather than a one-time patch ticket.

Where the browser is required only for a single legacy use case, the better control is usually retirement or replacement, not long-term exception approval. That is especially true when the vulnerable software has a known exploitation history and no business case strong enough to justify normal internet access.

What to check after patching for signs of compromise

Once the update or mitigation is in place, review logs and endpoint telemetry for earlier exploitation. The key question is whether the browser was merely vulnerable or whether it was already used as an execution foothold before the fix landed.

Look for suspicious process launches, unusual child processes from the browser, odd script or document activity, and follow-on behaviour that suggests an attacker moved from initial code execution into persistence or credential access. Even when the browser is the entry point, the real damage often appears later in the chain.

If you find evidence of exploitation, treat the endpoint as potentially broader than a browser incident. A browser RCE can be the start of lateral movement, data theft, or credential harvesting, so the response may need to extend beyond patching into account review, session review, and incident containment.

The CISA Known Exploited Vulnerabilities Catalog remains the best external operational reference for confirming that this is a real exploitation-priority issue, not just a theoretical browser bug.

Risk and Threat Considerations

A browser remote code execution flaw matters because it collapses the normal trust boundary between web content and endpoint execution. If attackers can trigger code through a browser that is still present in the estate, they may gain an initial foothold without needing user credentials first.

Failure mechanism: A malicious page, document, or redirected link reaches a vulnerable browser instance and triggers code execution on the endpoint, after which the attacker can run further payloads, inspect the host, or stage lateral movement.

Impact: The affected endpoint may be used for malware installation, credential theft, data access, or additional internal compromise, and any delay in removal or patching extends the window for exploitation.

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 CIS Controls v8, NIST SP 800-53 Rev 5 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	The subject is an actively exploited vulnerability requiring prioritised remediation and verification.
Recommendation — Prioritise, track, and verify remediation for the vulnerable browser across the estate.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The answer centers on applying vendor updates and mitigating a known exploited flaw.
	RA-5 — Vulnerability Monitoring and Scanning	Exposure confirmation and post-fix validation require continuous scanning and review.
Recommendation — Apply approved updates or mitigations and verify remediation across affected endpoints. Scan for remaining Internet Explorer exposure and validate that remediation removed the vulnerable path.
OWASP ASVS	V15 — Secure Coding and Architecture	Legacy browser dependencies and insecure exposure handling are architecture concerns, not just patching tasks.
Recommendation — Remove or isolate legacy browser dependencies that keep an RCE path reachable.
MITRE ATT&CK	T1203 — Exploitation for Client Execution	This CVE is about code execution through a client-side browser exploit path.
Recommendation — Hunt for client-execution indicators and follow-on activity after browser exploitation.

Practitioner Guidance

What to prioritise: Patch or remove the browser everywhere it still exists, then concentrate on the endpoints that can reach the internet or open untrusted content. Those systems present the highest immediate exposure.

What to verify: Confirm the update is actually applied, confirm the vulnerable browser cannot still be launched through legacy workflows, and confirm there is a log trail for the period before remediation so you can assess whether compromise already occurred.

Common mistake: Treating this as a simple software update problem when the real issue is exposure plus potential prior execution. If you only patch and do not review for signs of abuse, you may close the vulnerability while leaving an active intrusion in place.

Practitioner takeaway: For actively exploited browser RCEs, the safest response is to eliminate exposure first, patch second, and investigate for pre-remediation compromise in parallel.