Is CVE-2025-53770 (Microsoft SharePoint Deserialization of Untrusted Data) being exploited in the wild?

By NHI Mgmt Group Editorial Team Updated October 19, 2026 Domain: Threats, Abuse & Incident Response

Yes. CISA added CVE-2025-53770 to its Known Exploited Vulnerabilities catalogue on 20 July 2025, 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 Server on-premises contains a deserialization of untrusted data vulnerability that could allow an unauthorized attacker to execute code over a network.

What “exploited in the wild” means for this SharePoint CVE

This is not a theoretical vulnerability. “Exploited in the wild” means there is credible evidence of real attack activity, not just proof-of-concept code or a vendor warning. For a server-side deserialization flaw, the practical question is whether exposed on-premises SharePoint instances are reachable by attackers and whether compromise could be used for code execution, persistence, or follow-on theft.

For vulnerability triage, the most useful interpretation is operational: treat the issue as already under active attack until you have confirmed otherwise. That means inventorying the exact SharePoint servers you run, confirming whether any are internet-facing or reachable through partner paths, and assuming the exposure window is shorter than the patch window.

Teams should also distinguish “patched” from “safe.” Deserialization RCE issues often leave room for post-exploitation activity if the attacker obtained access before remediation. If you are only asking whether the CVE is being exploited, the answer should still trigger a compromise-minded response, not just a patch ticket.

For a broader response playbook on actively exploited issues, Zero-Day and Exploited Vulnerabilities Guide covers the triage pattern practitioners use when a flaw moves from disclosure to confirmed exploitation.

Why deserialization flaws become high-priority attack paths

deserialization of untrusted data is dangerous because the application may convert attacker-controlled input into objects or commands before the system has a chance to validate intent. In a product like SharePoint Server, that creates a direct path from network reachability to code execution, which is why these issues are so often treated as emergency response events.

The key security failure is trust in input that should never be trusted. If an attacker can shape the payload and trigger the vulnerable code path, they may execute actions as the SharePoint process or adjacent service context. That can expose content, credentials, service tokens, configuration material, or internal data paths used by the server.

For readers who want the mechanism itself, Insecure Deserialisation Guide explains why object injection and gadget chains are so often tied to remote code execution in .NET and other runtimes.

When exploitation is confirmed in the wild, the concern shifts from “can this be triggered?” to “what did the attacker do after entry?” That is especially important for SharePoint because exploitation on an externally reachable collaboration platform can become a staging point for broader internal access.

What to verify before you assume the environment is clean

The first check is simple: identify every SharePoint Server deployment, confirm whether it is on-premises, and verify whether the exposed instance was reachable during the relevant exploitation window. If the system was internet-facing, the likelihood of attempted exploitation is materially higher than for a segmented internal deployment.

Next, look for signs of post-exploitation rather than only the initial request pattern. For server-side code execution issues, useful evidence includes unexpected processes, new web shells, unusual IIS activity, modified application files, suspicious scheduled tasks, and authentication events that do not match normal admin behaviour. If SharePoint is tied into adjacent identity or file services, review those logs too.

Keep the response grounded in authoritative sources. The vendor advisory tells you the affected build and the required fix or mitigation, while the CISA Known Exploited Vulnerabilities Catalog is the best public indicator that exploitation is confirmed and prioritised by US government guidance.

For prioritisation and exposure mapping, the NIST National Vulnerability Database remains useful for canonical CVE records, while the CVE Program is the reference point for the vulnerability identifier itself.

Risk and Threat Considerations

This kind of flaw is high risk because it combines network reachability, code execution potential, and a widely deployed enterprise application. If an attacker can trigger deserialization with crafted input, the result can be immediate foothold on a system that often has access to sensitive content and internal trust relationships.

Failure mechanism: The attacker abuses an unsafe deserialization path to make the application instantiate or process attacker-influenced objects, then leverages that execution context to run code or stage follow-on activity.

Impact: A successful exploit can lead to remote code execution, web shell deployment, credential or secret exposure, lateral movement, and persistence on the SharePoint host.

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 CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Confirmed exploitation requires rapid prioritisation and exposure tracking.
Recommendation — Prioritise and remediate the SharePoint CVE using continuous vulnerability management.
NIST CSF 2.0	ID.RA-01 — Asset Vulnerability Assessment	The answer depends on identifying exposed SharePoint assets and their exploitability.
	PR.IP-12 — Vulnerability Mitigation	The response centers on applying vendor fixes or mitigations promptly.
Recommendation — Assess exposed SharePoint assets and classify the CVE as an active risk. Apply the vendor fix or mitigation and track completion for the vulnerable SharePoint servers.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	Active exploitation calls for monitoring vulnerable hosts and validating exposure.
	SI-2 — Flaw Remediation	The flaw requires rapid remediation and verification on affected systems.
Recommendation — Scan exposed SharePoint systems and verify remediation status under RA-5. Remediate the SharePoint flaw promptly and confirm the fix is deployed.

Practitioner Guidance

What to prioritise: Treat CISA KEV listing as an escalation trigger. If the server is internet-facing or was exposed during the active exploitation window, prioritise containment, patching, and compromise assessment before routine maintenance work.

What to verify: Confirm whether the vulnerable instance was reachable, whether the vendor fix or mitigation is applied, and whether logs show suspicious requests, process launches, file changes, or newly created admin artefacts around the exposure period.

Decision rule: If you cannot patch immediately, isolate the server, restrict access as tightly as possible, and hunt for evidence of initial access and persistence before restoring normal exposure.

Practitioner takeaway: For a KEV-listed SharePoint deserialization flaw, patching is necessary but not sufficient, because exploitation in the wild means you must also answer the compromise question.

Deepen Your Knowledge

Free weekly newsletter

Subscribe to the NHI & AI Identity Journal

The latest on NHI and Agentic AI security – articles, research, breaches, news and events every week.

Bonus 33% off our NHI Course when you subscribe.

NHIMG Editorial Note
Reviewed and updated by the NHIMG editorial team on October 19, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org