CISA reported that a remote code execution flaw affecting Microsoft SharePoint, patched by Microsoft in May, is now being actively exploited. The key point is therefore no longer just the existence of a fix, but the change in the vulnerability’s operational status: a weakness that was already documented and patched has moved into the realm of real-world exploitation, with a clearly higher level of urgency for teams responsible for SharePoint environments. The initial source relayed here is the alert picked up by BleepingComputer from CISA’s communication about a SharePoint RCE flaw now observed in real-world attacks.

For organizations that use SharePoint, especially in on-premises or hybrid environments, this change in context requires an immediate reassessment of exposure. An RCE vulnerability on a central collaboration component, often connected to enterprise authentication, document workflows, and sometimes other Microsoft building blocks, can lead to server compromise, execution of arbitrary payloads, data theft, and pivoting into the rest of the information system. In highly interconnected environments, the impact goes far beyond the document platform alone.

At this stage, the public alert mainly emphasizes two factual elements: the flaw has already been patched by the vendor, and it is now the subject of active exploitation reported by CISA. When a vulnerability enters CISA’s catalog of exploited flaws, this is in practice a strong prioritization signal for CISOs, operations teams, and Microsoft administrators. Even when no full exploitation details are made public, the existence of observed attacks is enough to change the level of risk.

In this type of case, the operational difficulty often lies in a false sense of security: many teams know that a patch exists, but have not always verified its effective deployment across all SharePoint farms, application nodes, preproduction servers, or less visible environments. Patching delays, restricted maintenance windows, application dependencies, and the complexity of SharePoint farms frequently contribute to leaving exposed surfaces in place longer than expected.

Microsoft’s official communication remains the primary reference for precisely identifying the CVE identifier or identifiers involved, the affected versions, and the update packages to apply. CISA, for its part, serves here as the priority trigger by confirming active exploitation. BleepingComputer relayed this development, but technical actions must be driven from Microsoft bulletins and the vendor’s recommendations. In the absence of complete and verified elements in the secondary source, it is preferable not to over-specify a CVSS score, a single CVE identifier, or an unconfirmed detailed exploitation chain.

For French teams, this type of alert must be handled with the same rigor as an Internet-exposed perimeter vulnerability. Environments hosted at OVH, Scaleway, o2switch, or on internal infrastructure are not protected by default against an already exploited application flaw if the vulnerable SharePoint component remains accessible. The immediate priority is therefore twofold: confirm the actual patch level, then look for indicators of compromise on systems that may have been exposed before the update.

Affected versions

The communication relayed by CISA and BleepingComputer indicates that this is a Microsoft SharePoint flaw patched in May and now actively exploited. However, the secondary source provided does not by itself detail the full inventory of affected and fixed versions. To remain strictly factual, it is therefore necessary to rely on the Microsoft advisory corresponding to the vulnerability targeted by CISA.

The certain points to retain are as follows:

  • Product concerned: Microsoft SharePoint.
  • Nature of the flaw: remote code execution (Remote Code Execution).
  • Status: patched by Microsoft in May, then reported as actively exploited by CISA.
  • Expected action: identify the exact SharePoint version deployed in the organization and compare it with the associated Microsoft security bulletin.

In practice, teams must establish a precise map without delay:

  • SharePoint instances in production;
  • secondary farms and test environments;
  • servers published through a reverse proxy or directly exposed;
  • forgotten nodes, recovery servers, old VM images, and reactivatable snapshots;
  • hybrid integrations with Microsoft 365 or other internal services.

The verification must be carried out based on official Microsoft references, by looking for the security bulletin published in May for the SharePoint RCE flaw mentioned by CISA. Depending on the vendor’s practices, the useful information is generally found in:

  • the Microsoft Security Response Center page;
  • the Microsoft security update guide;
  • the SharePoint product documentation listing the applicable security updates.

In environments where the software inventory is not fully reliable, it is recommended to verify locally the presence of installed updates, the state of SharePoint binaries, and the history of Windows/SharePoint patches. A simple assumption of compliance is not enough, especially when active exploitation is confirmed.

Examples of useful checkpoints on the system side:

  • Windows Update history;
  • patches installed via Get-HotFix where relevant;
  • SharePoint build version reported by Central Administration or inventory tools;
  • version consistency across all nodes in the same farm.

Method point: on SharePoint, a partially updated farm may leave risk in place if a vulnerable node remains accessible, directly or indirectly. Compliance must be verified server by server, not only at the service’s declared level.

If your organization relies on a managed service provider or a hosting provider, you must obtain explicit confirmation of the fixed versions deployed, the date the patch was applied, and the exact scope covered. In managed hosting cases, a frequent ambiguity concerns the boundary of responsibility between the Windows infrastructure, SharePoint itself, and the ancillary components published at the front end.

Attack vector

An RCE flaw in SharePoint means that an attacker can, under certain conditions described by the vendor, trigger code execution on the target server. Even without disclosing a detailed exploitation chain, the operational severity is high for several structural reasons specific to SharePoint.

First, SharePoint is often positioned as a strategic application: intranet portal, document management system, project space, document workflow, content publishing, connector with other Microsoft services. It therefore concentrates sensitive data, privileged service accounts, application secrets, and trust relationships with Active Directory, SQL Server, Exchange, Teams, or other internal building blocks. Code execution on a SharePoint server is not an isolated incident; it can become the entry point for a broader compromise.

Next, SharePoint servers are frequently accessible remotely, at least for internal users, and sometimes for partners or remote staff via VPN, application proxy, or web publishing. As soon as a vulnerability is remotely exploitable, the attack surface is potentially significant, especially if exposed interfaces respond from the Internet or from poorly segmented network segments.

Concretely, the impact can take several realistic forms:

Code execution on the application server

The central scenario remains arbitrary code execution in the context of the affected service. Depending on the privileges of the compromised process and the machine’s configuration, the attacker can:

  • deploy a web shell;
  • create or modify scheduled tasks;
  • install a backdoor;
  • launch system commands;
  • collect secrets present on the server.

On a Windows host, this may result in unusual processes appearing, files being written into web or temporary directories, or commands being executed via powershell.exe, cmd.exe, wscript.exe, or other system interpreters.

Access to content and application secrets

Once on the server, an attacker may seek access to SharePoint content, connection settings, service accounts, and configuration information. Even if the flaw does not immediately grant domain administration privileges, it may provide enough access to prepare lateral movement. Application secrets, technical accounts, and connections to other systems are priority targets.

Pivoting within the information system

The major risk, from a CISO’s point of view, is pivoting. A compromised SharePoint server can serve as a relay toward:

  • the associated database;
  • other servers in the farm;
  • file shares;
  • directories and authentication services;
  • administrator workstations that connect to the platform.

In environments where application servers have broad network permissions, the attacker can turn an application vulnerability into a foothold for internal reconnaissance, privilege escalation, and expansion of the compromise.

Stealthy persistence

Collaboration platforms are also good targets for persistence. A compromised SharePoint server can host artifacts that are hard to notice if the organization does not have sufficiently granular application and system monitoring. Files added in web directories, periodically triggered scripts, modified technical accounts, or installed services may remain in place after a simple patch if no post-compromise investigation is conducted.

The change in status to active exploitation is precisely what makes detection essential. An organization that applies the patch today but was compromised yesterday solves only part of the problem: it closes the door, but does not necessarily address the intrusion that has already occurred.

Why the shift to active exploitation changes the priority

As long as a flaw remains theoretical or only demonstrated in the lab, some teams may place it behind more visible operational emergencies. When CISA confirms active exploitation, the question is no longer whether the flaw is interesting to attackers, but whether your environment has already been targeted or will be in the short term.

This development should lead to revisiting three timelines:

  • identification time for the affected servers;
  • deployment time for the Microsoft patch;
  • investigation time to look for traces of prior exploitation.

In mature organizations, these three workstreams should be launched in parallel. Waiting until patching is complete before starting the hunt for IoCs unnecessarily lengthens the risk window.

Impact

The potential impact of an actively exploited SharePoint RCE is high, even in the absence of complete public details on the observed attack chains. The most likely consequences fall into four areas.

Server compromise

The first effect is the loss of integrity of the SharePoint server. The attacker can alter the system, drop tools, manipulate logs, or modify the configuration. If the host plays a central role in the farm, service availability may also be affected, deliberately or not.

Confidentiality breach

SharePoint often hosts HR, financial, legal, technical, or commercial documents. A compromise can expose:

  • business documents;
  • project metadata;
  • internal lists;
  • attachments;
  • authentication or configuration information.

For organizations subject to regulatory obligations, this dimension may trigger internal notifications, impact analyses, and, depending on the case, obligations toward authorities or partners.

Lateral movement and increased overall risk

A compromised collaboration application frequently becomes a springboard. Service accounts, tokens, secrets in memory, trusted connections, and administration habits create a context favorable to lateral movement. A SharePoint server is not only a target; it is also a bounce platform.

Deployment of post-exploitation tools

When active exploitation of a flaw is observed in the wild, the use of classic post-exploitation tools must be considered: PowerShell scripts, in-memory payloads, web shells, scheduled tasks, locally added accounts, IIS modifications, or persistent services. The details vary depending on the campaigns, but the logic remains constant: stabilize access, evade detection, and prepare the next stages of operations.

How to patch

The fix already exists, which simplifies the decision: the Microsoft security update corresponding to the SharePoint flaw reported by CISA as actively exploited must be applied. The difficulty is not knowing whether to patch, but doing it quickly, completely, and cleanly across all affected nodes.

As the provided source does not detail the exact patch number or the full version matrix, the procedure below remains deliberately grounded in verifiable best practices and official Microsoft documentation.

1. Identify the exact Microsoft bulletin

Start by finding the official Microsoft advisory linked to the SharePoint flaw mentioned by CISA. The reference sources are:

  • the Microsoft Security Response Center;
  • Microsoft’s Security Update Guide;
  • SharePoint update documentation.

From this reference, note:

  • the CVE identifier;
  • the affected SharePoint editions;
  • the corresponding security update;
  • any prerequisites;
  • the necessary post-installation operations.

2. Back up and prepare the maintenance window

Before deployment, verify application and system backups, as well as rollback capability compatible with your internal procedures. On SharePoint, farm-level patch changes must be prepared carefully, especially if customizations or third-party integrations are present.

3. Deploy Windows/SharePoint updates

Depending on your administration model, remediation will generally go through Microsoft update mechanisms or installation of the specific SharePoint package provided by the vendor. Examples of generic commands useful on the Windows side to inventory or trigger administration operations, to be adapted to your internal procedure:

Get-HotFix

This PowerShell command can help verify patches installed on the server, even if final validation must be done against the Microsoft bulletin and the expected SharePoint version.

wmic qfe list brief

In some environments, this inventory can complement verification of the patches present. It does not replace application-level validation on the SharePoint side.

If your organization uses centralized tools such as WSUS, Microsoft Endpoint Configuration Manager, or an equivalent patch management chain, make sure the May SharePoint patch has indeed been approved, distributed, and installed on all affected servers.

4. Finalize the SharePoint update

Depending on the SharePoint version and the nature of the patch, additional steps may be required after installation, for example at the farm configuration level. Teams must strictly follow the vendor procedure. In a SharePoint context, it is common to have to verify the state of the farm after patching, node consistency, and the proper functioning of application services.

SharePoint administration commands can be used to check the overall state, for example:

Get-SPFarm Get-SPServer

These commands illustrate the need to verify the state of the farm, but the exact sequence depends on the deployed version and Microsoft guidance. You must refer to the official patch documentation to avoid any unsuitable operation.

5. Verify the target version and test critical uses

Once the patch is applied:

  • check the build version reported by SharePoint;
  • verify that all nodes show a consistent level;
  • test user access;
  • test critical workflows and connectors;
  • monitor application and system logs during the following hours.

The essential point is not only installation of the patch, but confirmation that the fixed version published by the vendor is actually active across the entire exposed scope.

6. If SharePoint is outsourced

For environments operated by a third party, formally request:

  • the reference of the patch applied;
  • the date and time of deployment;
  • the list of servers covered;
  • confirmation of post-patch checks;
  • the elements of the search for indicators of compromise carried out.

In a managed services contract, patching alone is not enough: it is also necessary to clarify who conducts the potential compromise investigation, who retains the logs, and who drives escalation in the event of positive IoCs.

Detection

Because active exploitation is confirmed by CISA, detection must be treated as a priority at the same level as patching. The objective is to answer two questions:

  • are vulnerable SharePoint servers still exposed?
  • has exploitation already taken place before the patch was applied?

Without publishing unconfirmed IoCs, robust investigation paths that are immediately usable by SOC teams, internal CERTs, or Windows/SharePoint administrators can be listed.

Web and IIS logs

IIS logs are a central source for spotting:

  • unusual requests to SharePoint endpoints;
  • repeated sequences from the same IP address;
  • spikes in 500, 401, 403, or 404 errors around sensitive application paths;
  • abnormal strings in URL parameters or HTTP headers.

Examples of fields to examine:

  • cs-uri-stem ;
  • cs-uri-query ;
  • c-ip ;
  • cs(User-Agent) ;
  • sc-status ;
  • time-taken.

Requests to rarely used SharePoint paths, atypically encoded parameters, bursts of very closely spaced access attempts, or user-agents inconsistent with your usual usage may justify deeper investigation.

Windows and PowerShell events

A successful RCE can trigger system-side artifacts. Teams should examine:

  • abnormal process creations;
  • launches of powershell.exe by IIS or SharePoint processes;
  • use of cmd.exe, cscript.exe, wscript.exe, mshta.exe;
  • newly created scheduled tasks;
  • added or modified services;
  • unusual logon events on the server.

If advanced logging is enabled, look for suspicious command lines, remote downloads, system inventory commands, or access to application web directories.

Files and directories to monitor

Directories likely to host persistence artifacts or temporary drops must be inspected:

  • IIS web directories;
  • SharePoint application directories;
  • C:\inetpub\wwwroot\ ;
  • system temporary directories;
  • unexpected script or extension locations.

Useful signals include:

  • recently created files outside normal deployment cycles;
  • unusual extensions;
  • unknown ASPX files;
  • scripts or binaries whose signature and origin are not established.

Accounts and privileges

Check:

  • local accounts added recently;
  • changes to administrator groups;
  • modified service accounts;
  • new delegations or permissions on the farm.

An application compromise can remain discreet while still being accompanied by privilege adjustments intended to facilitate persistence.

Outbound network traffic

A SharePoint server is generally not intended to initiate arbitrary traffic to the Internet. Unusual outbound connections may reveal:

  • a payload download;
  • command-and-control communication;
  • exfiltration;
  • a reconnaissance or pivot phase.

Monitor in particular:

  • new destinations;
  • unexpected ports;
  • encrypted communications to unknown hosts;
  • traffic spikes outside normal hours.

Examples of immediate checks

A few quick checks can help prioritize the analysis:

Get-ChildItem -Recurse C:\inetpub\wwwroot\ | Sort-Object LastWriteTime -Descending | Select-Object FullName, LastWriteTime -First 50

This PowerShell command makes it possible to quickly identify recently modified files in the IIS web tree. It does not prove a compromise, but it can highlight unexpected artifacts.

Get-ScheduledTask | Sort-Object TaskPath, TaskName

Useful for listing scheduled tasks and spotting abnormal entries, especially if they were created outside usual administration procedures.

Get-WinEvent -LogName Security -MaxEvents 200

Provides an initial view of recent security events, to be supplemented with filters adapted to your logging policy.

In a SOC, these checks must be correlated with proxy, EDR, firewall, and directory logs. The challenge is to identify whether suspicious behavior on SharePoint is part of a broader sequence: abnormal authentications, unusual administrative connections, outbound traffic to rare destinations, or account modifications.

Mitigation

The Microsoft patch remains the priority remediation measure. If you cannot patch immediately, temporary measures can reduce exposure, without replacing the update.

  • Reduce network exposure: limit access to only necessary sources, disable any non-essential Internet publishing, and strengthen front-end filtering.
  • Restrict administration: prohibit administrative connections from unmanaged workstations and apply strict network segmentation around SharePoint servers.
  • Strengthen monitoring: temporarily increase retention and the level of analysis for IIS, Windows, EDR, and proxy logs.
  • Control service accounts: verify their privileges, secret rotation, and access scope.
  • Set up proactive hunting: look for web shell artifacts, scripts, and unusual scheduled tasks.

In the most sensitive environments, if the patch cannot be applied within acceptable timeframes, stronger measures must be considered, including temporary service restriction or partial disabling of external access. This decision involves a business trade-off, but active exploitation confirmed by CISA changes the level of risk acceptance.

For organizations that have a WAF or an application reverse proxy, it may be useful to enable more verbose logging and detection rules adapted to abnormal behavior targeting SharePoint. This does not guarantee blocking exploitation, but it can improve visibility and shorten detection time.

Ecosystem perspective and feedback

This type of alert illustrates a now classic pattern: a critical flaw is patched, but patching effort is not uniform across the ecosystem, then attackers industrialize exploitation against the organizations slowest to react. The operational value of the CISA announcement is precisely to remind us that a patched vulnerability is not a resolved vulnerability until actual deployment is confirmed everywhere.

For M365 and on-prem teams, the lesson is particularly important. Hybrid environments often create an illusion of generalized modernization, while part of the collaboration services remains hosted on internal or externally hosted legacy servers. SharePoint on-prem remains a sensitive component, with maintenance constraints sometimes heavier than those of other web applications. That is precisely what can lengthen remediation timelines.

The strategic best practice is to treat exposed SharePoint servers as high-priority assets, on the same level as a VPN, an authentication gateway, or a messaging front end. This implies:

  • a reliable inventory;
  • contractualized patching timelines;
  • enhanced monitoring;
  • regular compromise review exercises;
  • appropriate network segmentation;
  • a review of technical account privileges.

French organizations can usefully monitor CERT-FR communications when a risk of broad campaigns or active exploitation affects components widely deployed in enterprises. Even when no specific national alert has yet been published, the combination patch available + active exploitation confirmed by CISA is enough to justify immediate mobilization.

The official source to prioritize for technical actions remains the corresponding Microsoft advisory, supplemented by the CISA alert on active exploitation. The BleepingComputer coverage plays a role here in dissemination and contextualization, but remediation must be driven from vendor references and internal crisis management and patching procedures.

In practice, the most defensible sequence is simple: identify all SharePoint instances, confirm the fixed version published by the vendor on each node, look for indicators of prior compromise, then harden exposure and monitoring. To go further on hardening hygiene, attack surface reduction, and patch management organization, also see the resources in the /categorie/pratiques category.

Rubrique CVE
Partager
Retour aux actualités

Comments· No comments yet

Be the first to react.

Leave a comment