Is CVE-2025-53690 (Sitecore Multiple Products Deserialization of Untrusted Data) being exploited in the wild?

Yes. CISA added CVE-2025-53690 to its Known Exploited Vulnerabilities catalogue on 4 September 2025, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Sitecore Experience Manager (XM), Experience Platform (XP), Experience Commerce (XC), and Managed Cloud contain a deserialization of untrusted data vulnerability involving the use of default machine keys.

What the KEV listing means for this Sitecore flaw

CISA’s KEV inclusion is the clearest operational signal that this is not just a theoretical deserialization issue. For practitioners, the question is less “can this be exploited?” and more “where is Sitecore exposed, and what should be assumed already at risk?” The practical response starts with confirming which XM, XP, XC, and Managed Cloud instances exist and whether they are internet-facing or reachable from untrusted networks.

Because the weakness involves deserialization of untrusted data, the key concern is that attacker-controlled input can influence execution flow in ways that are difficult to detect from normal application logs. That makes this a deserialization problem first, and an exploitation-triage problem second. The defensive question is whether the application can be forced to process crafted payloads before any obvious abuse is visible.

For teams tracking exploited vulnerabilities at scale, the page belongs in the same triage stream as other actively exploited issues. The right comparison is whether your exposure is still present, not whether the vendor has already published a fix path. Use the CISA Known Exploited Vulnerabilities Catalog as the operational trigger for prioritisation, then validate the affected Sitecore footprint against the vendor advisory.

Why default machine keys make the exposure more serious

The vulnerability description matters because default machine keys are not a minor implementation detail, they are part of the trust boundary for how Sitecore processes and validates state. If those keys are predictable or shared, attackers may be able to turn a deserialization bug into a far more durable compromise path than a one-off request failure. In other words, the flaw is dangerous because the platform’s keying model can reduce the cost of reliable exploitation.

That makes post-exploitation review important even when the immediate vulnerability is patched. If an attacker was able to deserialize malicious content, they may have used the same weakness to create persistence or to preserve access across restarts and routine maintenance. At that point, patching alone is not enough, because the enterprise still has to answer whether server-side state, configuration, or session material was altered.

The most useful external references for version and exposure confirmation are the CVE Program for the record itself and the NIST National Vulnerability Database for structured record data and downstream correlation. Those sources help anchor the issue, but the operational priority remains whether the Sitecore deployment is still accepting risky input and whether any attacker activity preceded remediation.

What to do if patching is delayed or compromise is uncertain

If you cannot patch immediately, reduce exposure rather than waiting for a perfect maintenance window. That means isolating the affected Sitecore services, tightening inbound reachability, restricting management access, and reviewing whether any public-facing route can still submit content that reaches the deserialization path. If the platform must stay online, treat every untrusted input path as suspect until the fix is in place.

Vulnerability management is the right operational frame here because the decision is not just whether to patch, but how to manage exception risk while the vulnerability remains reachable. When the asset is customer-facing or supports sensitive workflows, delaying action should require explicit ownership, a documented compensating control, and a short expiry on the exception.

If there is any indication that the environment may already have been touched, review server logs, web tier logs, and authentication or session anomalies for the time window before remediation. For this class of flaw, the highest-value evidence is often indirect: new files, unexpected configuration changes, unusual outbound connections, or signs that the application server was used to stage later actions. Where the application may have exposed credentials, rotate any secrets, service accounts, or keys that could plausibly have been accessed during compromise.

Risk and Threat Considerations

This kind of deserialization flaw is attractive because it can convert a single crafted request into execution opportunities that are hard to distinguish from normal application behaviour. When a product also relies on default machine keys, the attacker may gain a more reliable path to persistence, replay, or session abuse than a simple injection bug would provide.

Failure mechanism: The application accepts attacker-influenced data into a deserialization flow, and the trust assumptions around machine keys reduce the protection that should normally constrain that input.

Impact: Successful exploitation can lead to code execution, persistence, session or state abuse, and follow-on access to adjacent systems or sensitive data if the server is trusted inside the environment.

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-7 — Continuous Vulnerability Management	CVE triage and exploit status are central to this actively exploited Sitecore issue.
Recommendation — Prioritise, verify, and remediate the exposed Sitecore systems under continuous vulnerability management.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The question is about an exploited software flaw and its remediation urgency.
	RA-5 — Vulnerability Monitoring and Scanning	Exposure confirmation and KEV-driven prioritisation depend on vulnerability monitoring.
Recommendation — Track the flaw, apply the vendor fix, and validate remediation across all affected hosts. Scan for exposed Sitecore instances and monitor them for exploitable conditions and remediation gaps.
OWASP ASVS	V15 — Secure Coding and Architecture	The issue is a deserialization design weakness that should be prevented by secure architecture.
	V14 — Data Protection	Default machine keys and possible state exposure make protection of sensitive material material to the case.
Recommendation — Eliminate unsafe deserialization paths and enforce safer trust boundaries in the application design. Protect server-side state and secret material so compromise of one path does not expose broader trust data.

Practitioner Guidance

What to verify: Confirm whether any Sitecore XM, XP, XC, or Managed Cloud deployment is exposed to untrusted input paths that reach the vulnerable deserialization logic, and verify whether default or shared machine keys are present anywhere in the stack.

Escalation / exception: If patching must wait, escalate the issue as an active exploitation concern, not a routine vulnerability backlog item. Keep the exception short-lived and require compensating controls that materially reduce reachability.

What practitioners underestimate: Teams often stop at the patch step and skip compromise review. With exploited deserialization issues, the more important judgement is whether the server’s trust state, not just its binary version, must be reset.

Practitioner takeaway: For KEV-listed deserialization bugs, the operational question is whether the environment can still be abused or was already abused, so patching, reachability reduction, and compromise review should happen together.