Is CVE-2020-1147 (Microsoft .NET Framework, SharePoint, and Visual Studio Remote Code Execution) being exploited in the wild?

Yes. CISA added CVE-2020-1147 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 .NET Framework, Microsoft SharePoint, and Visual Studio contain a remote code execution vulnerability when the software fails to check the source markup of XML file input.

Why this CVE is treated as actively exploited

CISA’s KEV catalogue is the practical signal here, because it is maintained for vulnerabilities with reliable evidence of exploitation in the wild. For this issue, the right operational question is not whether exploitation is theoretically possible, but whether the affected environment still has exposed .NET Framework, SharePoint, or Visual Studio components that could be reachable by an attacker before remediation completes. CISA Known Exploited Vulnerabilities Catalog NIST National Vulnerability Database

For defenders, “being exploited in the wild” means the issue has moved out of a purely advisory state and into an incident-response posture. That changes prioritisation: systems that look merely vulnerable on paper should be treated as likely exposure points until inventory, reachability and patch status are confirmed.

What the vulnerability means in practice

This CVE is a remote code execution flaw, so the security consequence is not limited to application instability or information disclosure. If an attacker can influence the vulnerable XML file input path and the source markup is not validated correctly, they may be able to execute code in the context of the affected service or application.

The practical implication is that exposure can vary by deployment role. A development workstation running Visual Studio, an intranet application using SharePoint, or a server hosting .NET Framework-based functionality may all present different blast radii, even when the same CVE is present.

For technical follow-up, treat the vendor advisory as the authoritative source for affected versions, update paths and any product-specific mitigation details, then cross-check exposure against the CISA KEV entry to make sure your remediation timeline matches the exploitation risk.

What to do if you cannot patch immediately

If patching is delayed, reduce attack surface first. Prioritise isolation of the affected service, limit exposure to trusted networks, and remove unnecessary access to the vulnerable component while you work through the vendor fix. Where the application is internet-facing, the risk is materially higher because exploitation attempts are often opportunistic once a KEV-listed issue is public.

Also check whether the vulnerable component is part of a broader workflow, such as a build pipeline, a content upload path, or a shared service used by multiple teams. In those cases, one vulnerable instance can create repeated access opportunities across environments, so compensating controls should be broader than a single host-level change.

If you need a structured response path for already-exploited issues, Zero-Day and Exploited Vulnerabilities Guide is the right internal reference for KEV triage, emergency mitigation and post-patch hunting.

Risk and Threat Considerations

KEV-listed vulnerabilities often attract fast follow-on exploitation because defenders, scanners and threat actors converge on the same public signal. Once a flaw is known to be exploited, unpatched systems become time-sensitive targets, especially where the affected software is widely deployed or exposed to untrusted input.

Failure mechanism: The application accepts XML-derived content without sufficiently validating the source markup, allowing malicious input to trigger code execution rather than being treated as data.

Impact: An attacker may gain remote code execution, which can lead to system compromise, lateral movement, payload delivery or persistence on the affected host.

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 and CIS Controls v8 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
MITRE ATT&CK	T1203 — Exploitation for Client Execution	RCE exploitation maps to adversary execution through a vulnerable client or app path.
Recommendation — Hunt for exploitation attempts and follow-on execution after vulnerable input handling.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	This CVE requires prompt flaw remediation and verification across affected systems.
	SI-4 — System Monitoring	Active exploitation warrants monitoring for signs of compromise and unusual execution.
Recommendation — Track and remediate the vulnerable software quickly, then verify deployment. Monitor affected hosts for suspicious execution, web shells and related indicators.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV-listed exploitation is a vulnerability management prioritisation problem.
Recommendation — Prioritise and remediate exploited vulnerabilities using exposure and exploitability signals.

Practitioner Guidance

What to prioritise: Confirm whether any instance of Microsoft .NET Framework, SharePoint or Visual Studio is reachable in production, internet-facing, or embedded in a high-trust workflow. For KEV-listed issues, reachability and business criticality should drive the order of work, not just asset count.

What to verify: Validate patch status against the vendor advisory, then check for signs of earlier compromise on the same systems, especially unexpected processes, web shells, suspicious child processes or abnormal application behavior. If the affected system exposes sensitive data or privileged functions, treat post-exploitation review as part of the remediation, not an optional follow-up.

Practitioner takeaway: Once CISA places a CVE in KEV, the question shifts from “is this exploitable?” to “have we already reduced exposure and checked for compromise before the next attempt arrives?”