Skip to content
Today
Sections

Security Independently confirmed2 publishers 2 min read Published Updated

SharePoint RCE detections keyed to one exploit will miss the other, after CVE-2026-63520 leaks early

A third party published CVE-2026-63520 before the planned date, and two public gadget chains now reach the same flaw by different routes. One signature will not cover both.

The Watch · Security desk

Send a correction

Illustration accompanying SharePoint RCE detections keyed to one exploit will miss the other, after CVE-2026-63520 leaks early
Generated illustration

What happened

  • Rapid7 published its CVE-2026-63520 analysis ahead of schedule after a third party leaked the details first.
  • Two research teams demonstrated the flaw with different LOB types and different gadget chains.
  • The root cause is DbTypeReflector passing an attacker-controlled type name straight to Type.GetType() with no allowlist.

Why it matters

  • What it limits constraint A detection keyed to the ObjectDataProvider path will not fire on the LosFormatter path, so single-signature coverage is a gap by construction.
  • Who's exposed exposure With both the auth bypass and the RCE now public, any internet-reachable vulnerable SharePoint is exposed without needing credentials.
  • Who has to decide decision Defenders have to detect the primitive, a model resolving an arbitrary assembly-qualified type on upload, rather than any one payload.
  • What it sets up precedent Rapid7 expects further gadget chains, so rules built on today's two will need to be rewritten again.

The grace period was the point of holding the writeup. Rapid7 says it planned to publish 30 days after the August 11 disclosure and moved the analysis up only because a third party put details out first [2]. What that early publication changed is not the vulnerability but its detectability, and that is the part defenders have to sit with.

The bug lives in SharePoint's Business Data Connectivity subsystem. In `DbTypeReflector.ResolveDotNetType()`, the attacker-controlled `TypeName` from a BDC model is passed straight to `Type.GetType()` with no allowlist [10]. There is a length gate: names under 15 characters fall through to a limited base path, but anything 15 characters or longer resolves directly, which is enough room for `System.Windows.Data.ObjectDataProvider` or any other assembly-qualified type in the GAC [11]. Upload a malicious `.bdcm` model, trigger entity execution, set properties, and a setter side-effect reaches OS command execution [9]. On its own that is authenticated code execution as the site service account [3]; bolt on the CVE-2026-55040 authentication bypass and the chain is unauthenticated [4].

The consequence sits in how two teams reached the same primitive. Rapid7 got there with a Database LOB system and an `ObjectDataProvider` gadget chain; VulnCheck used a `DotNetAssembly` LOB system and a `LosFormatter` chain [5]. That is at least two distinct exploit paths in public, both landing on the same instantiation flaw [c6d]. A detection written around the ObjectDataProvider payload does not fire on the LosFormatter one, and vice versa. Rapid7's own read is that more chains are likely [6], so any rule built on today's two payloads is already behind the next one.

The durable signal is the primitive, not the gadget: a BDC model that resolves a long, arbitrary assembly-qualified type through the reflector, regardless of which class the attacker eventually instantiates. This is not a new failure mode for the subsystem either. Rapid7 credits ZDI's CVE-2019-1257 writeup, which covered leveraging BDC models for unsafe .NET type instantiation, as prior work [13]. The analysis was carried out against SharePoint Server Subscription Edition build 16.0.19725.20210 [12].

What to watch

  • Whether Microsoft's fix adds a real type allowlist to DbTypeReflector or merely adjusts the 15-character length check.
  • Whether exploitation in the wild appears now that two gadget chains and the auth bypass are all public.
  • Which additional gadget chains predicted by Rapid7 turn up in public tooling, and how fast detections move to the primitive.

Clarity's read

What the record supports and how the coverage leans. The claims behind it follow.

Reality

Evidence72
Adoption40
Hype gap+5
Incentives45
Confidence70
Why these scores

Claim ledger

Ranked by verification strength, evidence, and original report placement.

  1. [1]

    On August 11, 2026, Rapid7 and Microsoft disclosed CVE-2026-63520, a remote code execution vulnerability affecting Microsoft SharePoint.

    Reported SupportedView cited source
  2. [2]

    Rapid7's technical analysis was originally scheduled for publication 30 days after disclosure, but the timeline was expedited because a third party published details of CVE-2026-63520.

    Reported SupportedView cited source
  3. [3]

    A remote authenticated attacker can leverage CVE-2026-63520 to execute arbitrary code on a vulnerable SharePoint server with the privileges of the SharePoint site's service account.

    Reported SupportedView cited source
  4. [4]

    When combined with the authentication bypass CVE-2026-55040, the resulting exploit chain is unauthenticated RCE against a vulnerable SharePoint server.

    Reported SupportedView cited source
  5. [5]

    Rapid7 exploited the issue using a Database Line-of-Business (LOB) system and an ObjectDataProvider-based gadget chain, while the VulnCheck analysis used a DotNetAssembly LOB system and a LosFormatter-based gadget chain.

    Reported SupportedView cited source
  6. [6]

    Rapid7 states defenders should account for the different exploitation paths when detecting CVE-2026-63520, and that it is highly likely other gadget chains may also be used.

    Reported SupportedView cited source
  7. [7]

    At least two distinct gadget chains for CVE-2026-63520 are already public, both reaching the same underlying flaw.

    Derived Supported
  8. [8]

    The vulnerability is an unrestricted .NET type instantiation and property-setting primitive in the DbTypeReflector class of SharePoint's Business Data Connectivity subsystem, which resolves arbitrary assembly-qualified type names from BDC model XML without any allowlist or safety enforcement.

    Reported SupportedView cited source
  9. [9]

    An attacker who can upload a malicious .bdcm model file and trigger entity execution can instantiate any .NET type available in the Global Assembly Cache, set arbitrary properties, and leverage property-setter side-effects to achieve OS command execution.

    Reported SupportedView cited source
  10. [10]

    DbTypeReflector.ResolveDotNetType() calls Type.GetType() directly on attacker-controlled TypeDescriptor TypeName values without validation.

    Reported SupportedView cited source
  11. [11]

    If a type name is fewer than 15 characters it falls through to a limited base class lookup path, but for any type name of 15 characters or more the method calls Type.GetType() directly with no restrictions on which assemblies or types are permitted.

    Reported SupportedView cited source
  12. [12]

    The technical analysis is based on SharePoint Server Subscription Edition version 16.0.19725.20210.

    Reported SupportedView cited source
  13. [13]

    Rapid7 credits prior work by the ZDI research team on CVE-2019-1257, which discussed leveraging BDC models for unsafe .NET type instantiation.

    Reported SupportedView cited source

Sources

2 independent publishers whose own reporting we read for this story.

  1. bleepingcomputer.com

    1 article · August 26, 2026

    Hackers target Microsoft SharePoint RCE chain with PoC exploit
  2. blog.rapid7.com

    1 article · August 24, 2026

    Rapid7 Analysis: Microsoft SharePoint Remote Code Execution (CVE-2026-63520)

Topics and entities

Topics

Entities