CVE-2020-1147: Microsoft .NET Framework, SharePoint, and Visual Studio Remote Code Execution Vulnerability

CVE-2020-1147 is a remote code execution vulnerability affecting Microsoft .NET Framework, SharePoint, and Visual Studio. It arises when the software fails to adequately check the source markup of XML file input, allowing an attacker who can supply crafted XML to run code in the context of the process that deserializes that content. For IT and security teams, this matters because those products are widely deployed in enterprise environments; successful abuse can give an attacker a foothold on servers or developer workstations that handle untrusted or semi-trusted XML.

Public detail on exact attack chains is limited to the vendor and CISA descriptions. Confirm affected builds, fixed updates, and any configuration prerequisites directly against the Microsoft advisory before acting.

How it works

The core issue is insufficient validation of XML markup before deserialization. When an application built on the affected components accepts XML input and deserializes it without properly verifying its source or structure, malicious markup can influence the deserialization process. An attacker who can deliver such input—through a file upload, document processing path, web request, or other channel that reaches the vulnerable component—may cause the hosting process to execute attacker-controlled code under that process’s privileges.

This is a classic unsafe-deserialization style failure tied to XML handling rather than a memory-corruption bug. Exploitation does not require the attacker to already have code execution; it requires the ability to supply the malicious XML to a vulnerable deserialization path. The resulting code runs as whatever identity the .NET, SharePoint, or Visual Studio process is using, which on servers is often a service account with meaningful access to local resources and possibly the domain.

Do not assume a particular gadget chain, trigger file type, or network vector beyond what the advisory states; treat any untrusted XML ingestion path in these products as in scope until proven otherwise.

Am I affected? How to find it in your systems

These components commonly appear on Windows servers running SharePoint farms, application servers that host .NET Framework workloads, build and developer machines with Visual Studio, and any system that loads .NET Framework libraries for XML processing. Inventory steps:

• Enumerate installed Microsoft products: check Add/Remove Programs, WMI/Win32_Product or equivalent inventory tools, and SharePoint/Visual Studio setup logs for the presence of .NET Framework, SharePoint Server/Foundation, and Visual Studio.
• Map versions and patch levels against the Microsoft security update guide entry for CVE-2020-1147; the advisory lists the precise updates that supersede the vulnerable code. Do not rely on generic “latest .NET” assumptions.
• Identify XML ingestion points: document upload libraries, custom .NET web services or APIs that accept XML, SharePoint features that process external or user-supplied markup, and CI/CD or design-time tooling in Visual Studio that loads XML project or data files.
• Review application and system logs for unusual process creation, unexpected child processes spawned by w3wp.exe, OWSTIMER, devenv.exe, or other hosts that perform XML deserialization, and failed or anomalous XML parsing events around the time of suspicious activity.

Telemetry signs of exploitation are not uniquely documented for this CVE; look for the general pattern of code execution following XML processing—new binaries written under service account profiles, outbound connections from those processes, or privilege escalation shortly after XML-related activity. Confirm any indicators against the vendor advisory and your own baselines.

How to remediate

Patch first. Apply the security updates Microsoft released for .NET Framework, SharePoint, and Visual Studio as listed in the official advisory for CVE-2020-1147. Follow CISA’s required action: apply updates per vendor instructions. Use your standard patch-management process (WSUS, ConfigMgr, Microsoft Update Catalog, or vendor-supplied SharePoint/Visual Studio installers) and verify installation via the update history or file/version checks the advisory recommends.

After patching:

• Restart affected services or hosts as required by the update so the new binaries are loaded.
• Re-inventory to confirm the vulnerable components are no longer present at the reported levels.
• Harden XML handling more broadly: prefer allow-listed schemas, disable unnecessary DTD or external-entity processing where the platform allows it, and avoid deserializing XML from untrusted sources in application code that sits on top of these frameworks.
• Ensure least-privilege service accounts for SharePoint and .NET application pools so that any future deserialization issue has a smaller blast radius.

If you can't patch immediately

Reduce exposure until the vendor updates can be deployed:

• Segment systems that run SharePoint or internet-facing .NET applications so they cannot reach sensitive internal networks; restrict management and developer workstations similarly.
• If a web application firewall or reverse proxy sits in front of SharePoint or custom .NET endpoints, consider virtual-patching rules that inspect and block suspicious or oversized XML payloads, while recognizing that signature-based controls are imperfect for deserialization flaws.
• Disable or restrict features that accept arbitrary XML uploads or external markup if business requirements allow; remove unused SharePoint web applications or Visual Studio components that are not required.
• Increase monitoring on the affected hosts: process-creation auditing, detailed logging for the relevant application pools, and alerts on anomalous child processes or network connections originating from XML-processing services.
• Limit who can upload or submit XML content and enforce authentication and authorization on every ingestion path.

These measures lower likelihood and impact but do not replace the official updates.

If your data may have been exposed

Actively exploited remote-code-execution vulnerabilities are frequently used to establish persistence and move laterally, which can lead to data theft or ransomware. Public reporting for this CVE does not document known ransomware use, but that does not mean compromise is harmless. If you have evidence of exploitation or cannot rule it out, follow your incident-response plan: isolate affected hosts, preserve logs and memory where feasible, rotate credentials that may have been accessible to the compromised process, and assess what data the process identity could reach. As a quick additional check, you can run a free exposure scan of your email addresses against known breach datasets to see whether credentials or personal data have appeared in prior incidents.