CISA’s required action for CVE-2020-1147 is to apply updates per vendor instructions. In practice, find every instance of Microsoft .NET Framework, SharePoint, Visual Studio 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 CVE-2020-1147 means for patching and exposure reduction
This is an exploited remote code execution issue in Microsoft .NET Framework, SharePoint, and Visual Studio, so the first task is simple: inventory where those products exist and confirm whether any instance is reachable from untrusted networks. If the vendor update cannot be applied immediately, reduce exposure by removing internet access or taking the affected system out of service until you can remediate.
Patch timing matters here because “apply updates per vendor instructions” is the right answer only if the affected platform can actually be reached and serviced cleanly. Treat the vendor advisory as the source of truth for product-specific remediation steps, and do not assume one patching process fits every .NET Framework, SharePoint, or Visual Studio deployment.
For organisations that run mixed Windows estates, the practical challenge is not the download itself but finding every installed and exposed instance. That includes servers, developer workstations, and any SharePoint environment where a delayed maintenance window can leave the vulnerable component live longer than expected.
How to mitigate when patching is delayed
When immediate patching is not possible, the safest mitigation is to shrink the attack surface until the fix can be deployed. That usually means isolating the affected host, blocking public reachability, and removing the vulnerable service from active use if you cannot confidently prevent hostile traffic from reaching it.
Where the product is business-critical, mitigation should be treated as a temporary control, not a substitute for remediation. If the exposed system must remain online, the organisation should document the exception, define the shortest practical window for completion, and assign ownership for verifying that the mitigation is still in place.
Use authoritative vulnerability references to support your prioritisation. CISA’s Known Exploited Vulnerabilities Catalog tells you why this issue deserves urgent handling, while the National Vulnerability Database helps you tie the CVE to your asset inventory and internal tracking.
For operational triage, the most useful companion control is vulnerability prioritisation. Zero-Day and Exploited Vulnerabilities Guide and Vulnerability Management Guide both support the practical sequence of scoping, prioritising, fixing, and verifying issues that are known to be exploited.
What to check after remediation
After patching or isolation, review logs for signs that the flaw was used before the fix landed. For an exploited RCE, that means looking for suspicious child processes, unexpected web activity, new files, abnormal service behaviour, and any lateral movement that followed the initial compromise.
If you find evidence of execution, the response should go beyond patching. Rebuild or clean the affected host as appropriate, validate adjacent systems that could have been touched, and check whether credentials, sessions, or administrative access may have been exposed during the incident window.
Post-remediation validation should also confirm that the vulnerable version is no longer reachable in practice, not just in documentation. A system that was patched but still externally exposed, misrouted, or shadowed by another service can remain a viable target even after the software update is installed.
Risk and Threat Considerations
Because this CVE was actively exploited, the main risk is not theoretical code execution but rapid compromise of exposed systems before a maintenance cycle completes. The danger increases when the vulnerable product is internet-facing or sits behind a trust boundary that defenders assume is already “safe”.
Failure mechanism: An attacker reaches the vulnerable component through normal application exposure, triggers remote code execution, and uses the resulting execution context to stage persistence, steal data, or move to nearby systems before defenders notice.
Impact: The result can include server takeover, service disruption, data exposure, and a wider compromise path if the affected host has access to internal resources or privileged operational functions.
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, NIST CSF 2.0 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 | CVE-2020-1147 requires rapid identification and remediation of exposed vulnerable systems. |
| Recommendation — Continuously inventory, prioritise, patch, and verify exposed vulnerable assets. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | This CVE response is fundamentally about applying vendor updates and managing exceptions. |
| RA-5 — Vulnerability Monitoring and Scanning | Confirm exposure and check for affected instances before and after remediation. | |
| Recommendation — Apply vendor fixes promptly and track remediation exceptions until closed. Scan for vulnerable .NET Framework, SharePoint, and Visual Studio instances and validate remediation. | ||
| NIST CSF 2.0 | PR.IP-12 — Vulnerability Management | The subject is an exploited vulnerability that must be prioritised, remediated, and verified. |
| Recommendation — Prioritise exploited vulnerabilities, remediate them, and confirm the fix took effect. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | RCE mitigation depends on eliminating reachable vulnerable components and reducing exposure. |
| Recommendation — Remove unnecessary exposure and constrain components that can lead to code execution. | ||
Practitioner Guidance
What to prioritise: Triage every internet-facing .NET Framework, SharePoint, and Visual Studio instance first, then work inward to internal systems that still have privileged reach or sensitive data access. Exposure, not just product presence, should drive the order.
What to verify: Confirm the exact mitigation state on each host, not just that a change ticket exists. The useful evidence is a vendor-aligned update record, a hardened exposure state, and a post-change log review that covers the period before and after remediation.
Escalation / exception: If you cannot patch quickly and cannot fully remove exposure, treat that host as an active security exception with explicit business approval and a short expiry. Long-lived exceptions are the common failure mode in exploited-vulnerability response.
Practitioner takeaway: For KEV-listed RCEs, the real decision is usually whether you can reduce exposure fast enough to survive the patch window, because if you cannot, the system should be isolated or removed from service until remediation is complete.
Related resources from NHI Mgmt Group
- CVE-2020-1147 (Microsoft .NET Framework, SharePoint, and Visual Studio Remote Code Execution)
- How do you patch or mitigate CVE-2020-1350 (Microsoft Windows DNS Server Remote Code Execution)?
- How do you patch or mitigate CVE-2020-0796 (Microsoft SMBv3 Remote Code Execution)?
- How do you patch or mitigate CVE-2020-0938 (Microsoft Windows Adobe Font Manager Library Remote Code Execution)?