CVE-2019-0604: Microsoft SharePoint Remote Code Execution Vulnerability

CVE-2019-0604 is a remote code execution vulnerability in Microsoft SharePoint. It stems from improper validation of application package markup, allowing an attacker who can supply a crafted package to run code in the context of the SharePoint application pool and the SharePoint server farm account. Because that account often has broad rights inside the farm, successful exploitation can give an attacker a strong foothold on collaboration infrastructure that many organizations treat as business-critical. The vulnerability has been associated with known ransomware use, so unpatched systems remain a high-priority risk.

Defenders should treat this as a classic input-validation failure on a widely deployed Microsoft server product and confirm every version, patch, and configuration detail against the official vendor advisory before acting.

How it works

The underlying weakness is CWE-20 (Improper Input Validation). SharePoint fails to adequately check the source markup of an application package before processing it. An attacker who can present a maliciously crafted package to a vulnerable SharePoint instance can cause the server to interpret that markup in a way that leads to arbitrary code execution. The resulting process runs with the privileges of the SharePoint application pool and the SharePoint server farm account, which typically have extensive access to content databases, configuration, and other farm members.

Exact package format, delivery path, and exploitation prerequisites are not detailed here; teams must obtain those specifics from the Microsoft advisory. In general terms for this class of flaw, the attacker needs a way to submit or install an application package that the SharePoint service will parse. Once code execution is achieved, the attacker can install further payloads, move laterally inside the farm, or deploy ransomware—consistent with the reported ransomware use of this CVE.

Am I affected? How to find it in your systems

Microsoft SharePoint is commonly deployed on-premises as SharePoint Server farms supporting intranet portals, document libraries, and custom applications. It may also appear in hybrid configurations. Inventory every Windows server that hosts SharePoint roles (web front end, application, search, etc.) and identify the installed product edition and build.

• Use your software asset management or configuration-management database to list all SharePoint Server installations.
• On each host, check installed programs, the SharePoint configuration database, or PowerShell cmdlets such as Get-SPFarm / Get-SPProduct to record the exact build.
• Compare those builds against the fixed versions listed in the Microsoft security update guide for CVE-2019-0604; do not rely on generic version ranges.
• Review IIS and SharePoint ULS logs for unusual application-package upload or activation activity, unexpected w3wp.exe child processes, or sudden changes to farm accounts. Correlate with EDR telemetry for anomalous code execution under the application-pool identity.

Any system still running an unpatched build that the vendor lists as vulnerable should be treated as exposed until proven otherwise.

How to remediate

The primary remediation is to apply the security updates Microsoft released for this vulnerability. Follow the vendor’s instructions exactly: identify the correct update package for your SharePoint edition and cumulative update level, test in a non-production farm if possible, then deploy to production and verify the build number afterward.

• Patch all SharePoint servers in the farm; partial patching can leave attack paths open.
• After patching, restart relevant services and confirm the farm is healthy.
• As hardening for this input-validation class, restrict who can upload or activate application packages, enforce least-privilege for the farm and application-pool accounts, and disable unnecessary sandbox or custom-solution features if they are not required.
• Keep SharePoint current with subsequent cumulative updates so that related fixes remain in place.

CISA’s required action is simply to apply updates per vendor instructions; that remains the definitive step.

If you can't patch immediately

When immediate patching is impossible, reduce the attack surface while you schedule the outage.

• Segment SharePoint servers so they are reachable only from trusted management and user networks; block direct internet exposure of administrative or package-upload endpoints.
• If a web application firewall or reverse proxy sits in front of SharePoint, enable or tune rules that inspect or block suspicious application-package uploads; treat this as virtual patching only, not a substitute for the official update.
• Temporarily disable or tightly control features that allow users to deploy custom application packages or sandboxed solutions.
• Increase monitoring: alert on new processes spawned by the SharePoint application pool, unexpected outbound connections from farm servers, and modifications to critical SharePoint configuration files or databases.
• Ensure recent, tested backups of content and configuration databases exist and are stored offline from the farm.

These measures lower likelihood and impact but do not eliminate the vulnerability; patch as soon as practicable.

If your data may have been exposed

Actively exploited vulnerabilities, especially those with known ransomware use, frequently lead to data theft or encryption. If you discover evidence of exploitation or cannot rule it out, follow your incident-response plan: isolate affected hosts, preserve logs and memory images, and engage forensic support. Rotate credentials for farm and service accounts, and review access to sensitive document libraries. As a quick additional check, you can run a free exposure scan of your email addresses against known breach data to see whether related credentials have already appeared in public dumps.