Is CVE-2023-29357 (Microsoft SharePoint Server Privilege Escalation) being exploited in the wild?

Yes. CISA added CVE-2023-29357 to its Known Exploited Vulnerabilities catalogue on 10 January 2024, 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 contains an unspecified vulnerability that allows an unauthenticated attacker, who has gained access to spoofed JWT authentication tokens, to use them for executing a network attack.

When a SharePoint Server flaw is added to CISA’s KEV catalogue, the practical assumption is that active exploitation is already established. For defenders, that shifts the question from “is it theoretical?” to “is the affected service exposed, and has it been abused already?”

Zero-Day and Exploited Vulnerabilities Guide is the right starting point for triage because it focuses on KEV-driven prioritisation, emergency mitigation, and post-patch hunting when exploitation is already happening.

In this case, the vulnerability matters because the reported exploitation path is not a simple crash or denial of service. It involves spoofed JWT authentication tokens, which means the flaw sits at the boundary between authentication trust and downstream execution, so compromise can progress quickly once an attacker can reach the vulnerable SharePoint instance.

For incident response, that means you should treat the server as potentially touched even if you have not yet seen obvious user-facing symptoms. The main follow-up is to confirm whether the SharePoint deployment was internet-reachable, whether the patch or mitigation was delayed, and whether logs show suspicious token use, unusual child processes, or unexpected web requests around the KEV publication date.

ToolShell SharePoint exploitation 2025 is useful context because it shows why SharePoint exploitation often requires both patching and compromise assessment, not patching alone, when attackers can persist through stolen or abused keys and authentication material.

The ransomware note in CISA’s listing should also change response priorities. If a KEV entry is linked to ransomware campaigns, the operational concern is no longer only initial access, but also rapid follow-on actions such as staging, credential theft, lateral movement, and recovery pressure against backup and administration paths.

CISA Known Exploited Vulnerabilities Catalog is the authoritative place to verify whether the item remains listed and to track the remediation expectation that CISA attaches to actively exploited flaws.

What “Exploited in the Wild” Means for a SharePoint Server CVE

For a vulnerability question like this, “in the wild” is a meaningful operational threshold. It indicates real attacker use, not just proof-of-concept research, so defenders should assume exploitation campaigns may already be scanning for exposed instances at scale.

That changes the decision model. Instead of waiting for a broad incident report, teams should assess whether the service is exposed, whether compensating controls are in place, and whether the environment has artifacts that would show earlier compromise if the server had been reachable before the fix was applied.

CVE Program provides the canonical vulnerability record structure, while NIST National Vulnerability Database is the common reference point for broader record context and technical lookup.

Because the direct answer already confirms KEV inclusion, the useful practitioner step is not to debate whether exploitation happened, but to decide what evidence would prove impact in your environment and whether you need to assume compromise until checks are complete.

Response Priorities When Patching Cannot Wait

When a KEV-listed SharePoint flaw is still unpatched, the priority is to reduce exposure immediately, then validate whether the system already shows signs of abuse. That usually means restricting reachability, tightening administrative access, and reviewing logs before and after the known exploitation window.

If patching has to wait, the key judgment is whether the service can be isolated without breaking business-critical use. If it cannot, you should compensate with tighter network controls, heightened monitoring, and an explicit decision on who is allowed to touch the server until remediation is complete.

Vulnerability Management Guide fits this workflow because it covers prioritisation, exceptions, verification, and remediation tracking for exploited vulnerabilities rather than treating patching as a one-step task.

For attacker-facing validation, it is also worth checking whether the server handled suspicious requests that line up with authentication abuse. If spoofed token use was possible, access logs alone may not be enough, so teams should corroborate with web, process, and endpoint telemetry where available.

Risk and Threat Considerations

This class of issue is risky because it can convert a web-facing application flaw into authenticated-looking execution. When attackers can leverage spoofed tokens or similar trust abuse, the boundary between external access and internal authority becomes thin, and exploitation can move faster than normal login monitoring expects.

Failure mechanism: The vulnerability is exploitable only when the service is reachable and the attacker can take advantage of the broken trust path around authentication material. Once that happens, the attacker may execute actions that look legitimate enough to bypass weak monitoring or delayed detection.

Impact: The result can be full server compromise, follow-on credential theft, and use of the SharePoint foothold as a launch point for ransomware-related activity or broader network intrusion.

Standards & Framework Alignment

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

CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Exploited CVEs require rapid prioritisation, remediation, and verification.
Recommendation — Prioritise KEV-listed flaws for immediate remediation and verify closure with rescans.
NIST CSF 2.0	PR.PS-修	This mapping is invalid and should not appear.

Practitioner Guidance

What to verify: Confirm whether the instance was internet-exposed, whether the CISA KEV due date was missed, and whether logs show unusual token-related requests, unexpected admin actions, or abnormal child processes around the exploitation window.

What to prioritise: Treat compromise assessment as part of the remediation plan, not a separate nice-to-have, because exploited SharePoint flaws can leave the attacker present even after the patch is applied.

Decision rule: If you cannot prove the server was unreachable during the active exploitation period, assume it may have been touched and review it for persistence, lateral movement, and stolen credentials before declaring recovery complete.

Practitioner takeaway: For KEV-listed SharePoint flaws, the correct response is to act as though exploitation has already happened, then prove otherwise through exposure review, patch status, and focused compromise hunting.