Is CVE-2019-0604 (Microsoft SharePoint Remote Code Execution) being exploited in the wild?

Yes. CISA added CVE-2019-0604 to its Known Exploited Vulnerabilities catalogue on 3 November 2021, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. Microsoft SharePoint fails to check the source markup of an application package. Any organisation running the affected product should treat remediation as urgent.

What makes CVE-2019-0604 dangerous in practice?

The operational issue is not just that the flaw exists, but that it was already being used against real targets. Once a SharePoint server is exposed to a known-exploited vulnerability, it becomes a high-value entry point for initial compromise, follow-on payload delivery, and post-exploitation activity. For actively exploited vulnerabilities, the practical question is always whether the asset is still reachable and whether compromise indicators are already present.

Because the flaw is in Microsoft SharePoint, the risk sits in the application boundary, not just in patch status. If the vulnerable service is internet-facing, or reachable from broad internal networks, an attacker can move quickly from discovery to exploitation. Treat the exposure as time-sensitive even if scanning has not yet shown obvious abuse.

For version and record confirmation, use the CVE Program entry and the NIST National Vulnerability Database as the authoritative starting points, then cross-check the vendor advisory for exact remediation details.

How should teams respond when exploitation is confirmed by KEV status?

KEV inclusion should be treated as an emergency triage signal, not a background prioritisation input. The right response is to verify whether the product is present, determine whether the vulnerable SharePoint instance is externally reachable, and then move remediation ahead of routine maintenance work. For known exploited issues, delay increases the chance that exploitation has already occurred or will occur before the next scheduled change window.

Where patching is available, apply it immediately on every reachable instance, including less obvious test, staging, or auxiliary environments that still expose the same service path. If the server supports business-critical workloads, coordinate a short maintenance window rather than waiting for a standard release cycle. This is especially important when the vulnerability is already linked to ransomware use, because attackers often exploit the same access path repeatedly once it becomes broadly operationalised.

When remediation guidance comes from CISA, the most important practical step is to align your internal urgency with the catalogue status and the vendor’s exact fix instructions. The CISA Known Exploited Vulnerabilities Catalog is the best reference for whether this is an active exploitation case, while the vendor advisory should drive the patch sequence.

What to do if patching must wait

If you cannot remediate immediately, reduce exposure rather than hoping the vulnerable service will remain uninteresting. Restrict network access to the SharePoint host, remove unnecessary internet exposure, and tighten administrative reach so only approved management paths can reach the system. For a vulnerable enterprise application, shrinking the reachable attack surface is the main compensating control while you wait for the fix.

At the same time, look for evidence of pre-positioning or post-exploitation activity. That means reviewing recent authentication events, webshell indicators, unusual process launches, unexpected child processes from the SharePoint service, and new or modified files in application directories. If the server is internet-facing, assume the window for stealthy compromise may already have opened.

If a system was exposed for any meaningful period after the KEV listing, treat it as a candidate for compromise assessment, not just patch verification. A clean patch does not prove the host stayed clean before remediation.

Risk and Threat Considerations

Known exploited application flaws often move from initial access to rapid persistence because attackers know defenders will patch first and investigate later. In this case, the threat is not abstract, it is a live exploitation path with ransomware relevance, which makes delayed action materially more dangerous than a routine vulnerability finding.

Failure mechanism: The vulnerable SharePoint component accepts attacker-controlled content in a way that can lead to remote code execution, allowing the attacker to run commands or drop tooling on the server before normal controls have a chance to intervene.

Impact: Successful exploitation can expose data, enable lateral movement, and create an entry point for ransomware or other follow-on activity. Even a brief exposure window can be enough for compromise, so the operational risk is highest on internet-facing or poorly monitored instances.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	ID.RA-01 — Asset Vulnerability Identification	Identifies exposed vulnerable assets that need urgent triage after KEV listing.
	PR.PS-03 — Configuration Management	Supports hardening and removing unnecessary exposure on vulnerable SharePoint servers.
	DE.CM-01 — Networks and Services Monitored	Supports monitoring for signs of exploitation and post-compromise activity.
Recommendation — Inventory exposed SharePoint instances and prioritise the vulnerable ones first. Apply secure configuration changes and remove unnecessary exposure paths. Monitor the SharePoint service for exploitation indicators and anomalous activity.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	Directly governs urgent remediation of a confirmed exploited vulnerability.
Recommendation — Patch or mitigate the SharePoint flaw as soon as the vendor fix is available.

Practitioner Guidance

What to prioritise: Confirm whether any SharePoint instance is still reachable, then patch or isolate the exposed server before spending time on low-value tuning. If multiple vulnerable systems exist, triage the ones with external exposure and business data first.

What to verify: Check for recent signs of compromise before and after remediation, including suspicious webroot changes, unusual worker process behaviour, and unexpected administrative actions. A successful patch is not a substitute for compromise assessment when exploitation was already credible.

Decision rule: If the instance was internet-facing or broadly reachable during the exposure window, assume higher compromise likelihood and escalate for incident review. If access was tightly restricted and you have strong monitoring, remediation can still be urgent, but the investigation scope may be narrower.

Practitioner takeaway: For a KEV-listed SharePoint RCE, urgency is driven by exploitation evidence, not by patch discomfort. Treat exposure as an incident-priority event until the host is remediated and checked for signs of abuse.