Yes. CISA added CVE-2019-9874 to its Known Exploited Vulnerabilities catalogue on 26 March 2025, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Sitecore CMS and Experience Platform (XP) contain a deserialization vulnerability in the Sitecore.Security.AntiCSRF module that allows an unauthenticated attacker to execute arbitrary code by sending a serialized .NET object in the HTTP POST parameter __CSRFTOKEN.
How to interpret CISA’s confirmation of active exploitation
CISA listing CVE-2019-9874 in the KEV catalogue means this is not a theoretical flaw to park in backlog. For this kind of issue, the practical question is whether the vulnerable Sitecore CMS or Experience Platform instance is reachable, internet-exposed, and still running the affected module path that accepts the malicious POST parameter.
That distinction matters because deserialization flaws move quickly from disclosure to weaponisation. If the product is present, the control objective is to confirm exposure, not just to confirm that a vendor advisory exists. Use the vendor advisory and the KEV catalogue as the authoritative sources for version and remediation details.
What the vulnerability changes operationally
This issue is a remote code execution path created by unsafe deserialization in a .NET component, so the main operational impact is full application compromise rather than a narrow data-only leak. An attacker does not need prior authentication if the vulnerable endpoint is reachable and the payload is accepted.
That means the first-priority asset is the application instance itself, followed by anything the web process can reach: configuration files, adjacent services, stored secrets, deployment credentials, and any internal network paths available to the server account. If the instance sits behind authentication, do not assume that reduces the risk enough to delay triage.
For the underlying mechanism, see the Insecure Deserialisation Guide for the common object-injection patterns that turn a parser bug into code execution, and the Zero-Day and Exploited Vulnerabilities Guide for how to triage vulnerabilities already being exploited in the wild.
What to do if you cannot patch immediately
If patching must wait, treat the instance as exposed and reduce blast radius at once. The immediate goal is to block the vulnerable request path, reduce reachability to the application, and increase monitoring for requests that try to submit serialized objects or unusual POST bodies to the CSRF token parameter.
Temporary compensating controls should be explicit and short-lived: restrict access to the application tier, tighten upstream filtering where possible, and watch for process creation, outbound connections, and web-shell behaviour from the Sitecore host. If the server account can read or write sensitive material, rotate any credentials or keys that may have been accessible during the exposure window.
Use the Vulnerability Management Guide to align the response with verified exposure, exception handling, and post-fix validation, and the Application Security Posture Management (ASPM) Guide to keep the vulnerable application and its exposure paths visible while remediation is in flight.
Risk and Threat Considerations
This vulnerability is attractive to attackers because deserialization RCE often offers reliable execution with little user interaction. Once an internet-reachable instance is found, exploitation can move directly to host compromise, persistence, and follow-on discovery of internal secrets or adjacent systems.
Failure mechanism: The application accepts attacker-controlled serialized input, reconstructs an object graph, and executes code paths that were never meant to process untrusted data. That turns one HTTP request into arbitrary code execution on the server.
Impact: A successful exploit can expose content, configuration, credentials, and internal network access, and it can create a foothold for lateral movement or re-exploitation until the vulnerable instance is remediated or isolated.
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 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-10 — Malware Defenses | Active exploitation calls for detecting payload delivery and post-exploit behaviour. |
| Recommendation — Harden malware defenses and monitor for post-exploitation activity on the Sitecore host. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | KEV-listed exploitation requires timely remediation of the deserialization flaw. |
| RA-5 — Vulnerability Monitoring and Scanning | Exposure confirmation and KEV triage depend on scanning and inventorying affected instances. | |
| Recommendation — Remediate the vulnerable Sitecore instance and verify the fix is deployed everywhere. Continuously scan for exposed Sitecore instances and prioritise KEV-listed findings. | ||
| OWASP ASVS | V15 — Secure Coding and Architecture | Unsafe deserialization is an application architecture weakness that demands secure design and input handling. |
| V16 — Security Logging and Error Handling | Confirmed exploitation needs logs that reveal malicious POSTs and server-side execution traces. | |
| Recommendation — Eliminate unsafe deserialization patterns and redesign the data flow to avoid untrusted object materialisation. Log deserialization errors and suspicious request patterns so exploitation attempts are visible. | ||
Practitioner Guidance
What to prioritise: Confirm whether any Sitecore CMS or XP instance is internet-facing or reachable from untrusted segments, then check whether the vulnerable module path is still exposed in production, staging, or forgotten legacy deployments. A public-facing instance deserves same-day validation, not routine backlog treatment.
What to verify: Collect evidence of last successful requests, suspicious POST bodies, process launches from the web tier, and any outbound connections that did not belong to normal application behaviour. If there is any doubt about pre-remediation abuse, treat the host as potentially compromised and investigate before declaring it clean.
Decision rule: If the application cannot be patched immediately, isolate it and rotate any credentials, session material, or service-account access the server process could have touched. If you can patch, still complete compromise checks afterward, because active exploitation means the patch does not answer the question of what happened before remediation.
Practitioner takeaway: For KEV-listed deserialization flaws, the right sequence is exposure check, containment, patching, and then compromise validation, not patch-first optimism.
Related resources from NHI Mgmt Group
- CVE-2019-9874 (Sitecore CMS and Experience Platform (XP) Deserialization)
- CVE-2019-9875 (Sitecore CMS and Experience Platform (XP) Deserialization)
- Is CVE-2026-20131 (Cisco Secure Firewall Management Center (FMC) Software and Cisco Security Cloud Control (SCC) Firewall Management Deserialization of Untrusted Data) being exploited in the wild?
- Is CVE-2019-16057 (D-Link DNS-320 Remote Code Execution) being exploited in the wild?