Two SharePoint flaws chain into code execution without a login

On 24 August, Rapid7 published a technical analysis of CVE-2026-63520, a vulnerability in the Business Data Connectivity subsystem of Microsoft SharePoint. Microsoft disclosed the flaw on 11 August and rates it 8.1 out of 10 on the CVSS scale, with a severity of Important. Rapid7 describes how an attacker who already holds a valid session can run commands on the server with the privileges of the SharePoint site service account. Chained with the authentication bypass CVE-2026-55040, the result is remote code execution with no login at all. Rapid7 states that publication was brought forward because a third party had already released details of the flaw.

What happens technically

Business Data Connectivity is the part of SharePoint that pulls data from external systems such as a database or a web service and presents it as though it had always lived in SharePoint. The configuration is described in an XML file with the .bdcm extension, and that file states, among other things, which .NET types the individual fields should carry. Rapid7 explains that the ResolveDotNetType method in the DbTypeReflector class passed the type name straight to Type.GetType with no check of whether the type was permitted. Type names shorter than 15 characters took a different and far more restricted path, while anything longer was resolved freely.

With no allow list in place, anyone able to upload their own .bdcm file can ask SharePoint to instantiate any .NET type in the Global Assembly Cache and set properties on it. Rapid7 assembled a chain in which the ObjectDataProvider class received a Process object as its instance, and the property assignment alone was enough to start the process. The command runs inside the IIS worker process w3wp.exe, which means it runs with the privileges of the service account. Rapid7 uploads the file to the BusinessDataMetadataCatalog folder and triggers the chain with a POST request to the /_vti_bin/client.svc/ProcessQuery endpoint. VulnCheck compared the code before and after the update and found a new function called ValidateSafeBcsType. From the August update onwards, SharePoint only admits types listed in the farm's BCSAllowedTypeNames list.

The two analyses that appeared on the same day took different routes in. Rapid7 used a Database type LOB system and a chain built on ObjectDataProvider, while VulnCheck used the DotNetAssembly type and the LosFormatter class, bound to a Finder that fires when someone opens the associated external list. Rapid7 writes that defenders must account for both, and that further working chains are likely to exist. The sources also describe the precondition differently. Rapid7 states that the attacker must be authenticated to exploit CVE-2026-63520 on its own, whereas Microsoft's own entry says an unauthorized attacker can execute code over a network, and the CVSS vector requires no privileges. Microsoft further records the vulnerability as neither publicly disclosed nor exploited, in an entry that has not been revised since 11 August, while at the same time flagging exploitation as more likely and attack complexity as high.

What this means for you if you run SharePoint yourself

If SharePoint sits on servers you operate yourself, this is the second half of a story you already know. The authentication bypass CVE-2026-55040 entered the CISA catalogue of exploited vulnerabilities on 18 August, according to VulnCheck, and on its own it hands an attacker a valid session. Our assessment is that CVE-2026-63520 is the link that makes that session genuinely dangerous, because it shortens the road from authenticated to command execution. The two flaws were fixed in separate rounds. Microsoft fixed CVE-2026-55040 on 14 July and CVE-2026-63520 on 11 August, and both updates cover Subscription Edition, SharePoint Server 2019 and SharePoint Enterprise Server 2016. You therefore need both rounds in place.

You should also assume that your detection will fall short if it looks for a single pattern. Rapid7 and VulnCheck reached the same goal through two entirely different chains, and Rapid7 says openly that more are likely out there. What we would look for is uploaded .bdcm files and new external lists that nobody requested, plus processes spawning under w3wp.exe. VulnCheck reports finding at least 8,500 SharePoint servers on the open internet once honeypots and duplicates are stripped out. If your server has been sitting there unpatched since 11 August, patching now is not the whole job. You also need to look for traces of someone who got there first.

Berigo recommends

• Install Microsoft's August update on every SharePoint server, and check that the July update against CVE-2026-55040 is in place as well. The August update is KB5002893 for Subscription Edition, KB5002894 and KB5002896 for SharePoint Server 2019, and KB5002905 and KB5002906 for SharePoint Enterprise Server 2016.
• Review the BusinessDataMetadataCatalog folder for .bdcm files you do not recognise. Check who uploaded them and when it happened.
• Alert on processes spawning under the IIS worker process w3wp.exe, and make sure detection covers more than one exploitation pattern.
• Treat servers that have been exposed to the internet without both updates as potentially compromised until the logs say otherwise.
• Decide whether the SharePoint server needs to be reachable from the internet at all.