CVE-2023-24955 is a code injection vulnerability in Microsoft SharePoint Server. CISA added it to the Known Exploited Vulnerabilities catalogue on 26 March 2024, which means attackers have used it in real attacks. Microsoft SharePoint Server contains a code injection vulnerability that allows an authenticated attacker with Site Owner privileges to execute code remotely.
What this vulnerability means in SharePoint Server
CVE-2023-24955 is a code injection flaw in Microsoft SharePoint Server, so the danger is not just a crash or service disruption. It can turn a normal authenticated session into a route for arbitrary code execution, which means the application boundary has been crossed and the server itself can be used as the attacker’s execution environment.
That matters because SharePoint often sits close to documents, workflow content, and internal collaboration data. When code injection is possible in a server role like this, the exposed system is not merely vulnerable software, it becomes a potential stepping stone into the wider environment.
Why authenticated Site Owner access is still dangerous
The primary condition here is important: the attacker must already be authenticated and hold Site Owner privileges. That does not make the issue minor. Privileged authenticated access is exactly where dangerous application bugs become practical, because the application is expected to trust that user path more than anonymous traffic.
In practice, this kind of weakness can let an insider, a stolen account, or a compromised collaborator escalate from content management into server-side execution. For the reader, the key lesson is that authentication alone is not a sufficient safety boundary if the application grants powerful roles broad server-side capabilities.
For general vulnerability context, the NIST National Vulnerability Database and the CVE Program remain the authoritative references for the record itself and for downstream product details.
How organisations should check exposure
Exposure review starts with simple asset inventory: identify every on-premises SharePoint Server instance, map where it is reachable, and confirm whether any server is internet-facing or reachable through exposed remote access paths. If the environment still has active administrative or site-owner accounts tied to the application, those accounts become part of the exposure picture too.
Vendor advisories and the KEV catalogue should be checked together, because the real question is not only whether a CVE exists, but whether your specific deployment is one of the systems that remains vulnerable and actively targeted. If you need a broader process lens for prioritising vulnerabilities like this, the Vulnerability Management Guide is a useful companion for asset scope, KEV-based prioritisation, and remediation tracking.
Remediation, detection, and post-exploitation review
Remediation should follow the vendor’s guidance for the exact SharePoint build in use, with compensating controls applied where patching cannot be immediate. That usually means reducing exposure, tightening who can hold powerful SharePoint roles, and watching for suspicious server-side activity until the issue is closed.
Detection does not end when the patch is installed. Organisations should review for signs of web shell activity, unexpected process creation, unusual application pool behaviour, and changes to files or configuration that could indicate the server was already used as an execution platform. Because this is an authenticated code injection issue, post-patch compromise review is as important as patching itself.
After any suspected exploitation, rotate any credentials, session material, or adjacent administrative secrets that may have been exposed through the compromised SharePoint host, especially where the server had access to other internal systems. If you need a concrete analogue for why server-side compromise can persist after patching, ToolShell SharePoint exploitation 2025 shows how attackers can keep code execution alive by stealing machine keys.
Risk and Threat Considerations
This vulnerability is dangerous because it combines a trusted application role with server-side code execution. An attacker who can obtain or abuse Site Owner access may be able to move from ordinary collaboration permissions into deeper control of the SharePoint server, which can expose content, credentials, and adjacent internal systems.
Failure mechanism: The application accepts crafted input from an authenticated privileged user and passes it into a code execution path, allowing the attacker to run server-side code instead of only performing normal site administration.
Impact: The compromised SharePoint host can become a foothold for persistence, lateral movement, data access, and further privilege abuse across the environment.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| NIST SP 800-53 Rev 5 | IA-2 — Identification and Authentication (Organizational Users) | Authenticated privileged users are central to this SharePoint flaw. |
| AC-6 — Least Privilege | Site Owner privilege is the condition that makes code injection exploitable. | |
| SI-2 — Flaw Remediation | The term is a KEV-listed vulnerability requiring prompt remediation. | |
| Recommendation — Restrict and monitor privileged SharePoint authentication paths for administrative users. Reduce SharePoint Site Owner and admin privileges to the minimum necessary. Prioritise remediation of the SharePoint flaw using KEV-driven vulnerability handling. | ||
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | This CVE needs inventory, prioritisation, and remediation tracking across assets. |
| Recommendation — Inventory SharePoint servers and track this CVE through vulnerability remediation workflows. | ||
| OWASP ASVS | V8 — Authorization | The exploit depends on privileged application authorization rather than anonymous access. |
| Recommendation — Verify that privileged site actions cannot reach dangerous execution paths. | ||
Practitioner Guidance
Why practitioners should care: Treat this as a server-compromise risk, not only an application bug. A SharePoint exploit in a privileged context can expose more than the local site, especially if the server has broad internal connectivity or access to business data.
What to watch for: Prioritise any deployment where high-value content, privileged site ownership, or external exposure intersects with delayed patching. The safest operational posture is to assume the server may have been targeted already and to verify both patch state and compromise state.
Related resources from NHI Mgmt Group
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.
Reviewed and updated by the NHIMG editorial team on October 17, 2026.
NHI Mgmt Group — the #1 independent authority on Non-Human Identity, IAM, and Agentic AI security. nhimg.org