Security1 distinct publisher2 min readUpdated
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

Compiled by The WatchSomething wrong?How this is made
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 [9]. 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 [10]. Upload a malicious `.bdcm` model, trigger entity execution, set properties, and a setter side-effect reaches OS command execution [8]. 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 [12]. The analysis was carried out against SharePoint Server Subscription Edition build 16.0.19725.20210 [11].
Follow any of these and your For You feed starts watching them — no settings page required.
Ranked by verification strength, evidence, and original report placement.
On August 11, 2026, Rapid7 and Microsoft disclosed CVE-2026-63520, a remote code execution vulnerability affecting Microsoft SharePoint.
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.
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.
When combined with the authentication bypass CVE-2026-55040, the resulting exploit chain is unauthenticated RCE against a vulnerable SharePoint server.
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.
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.
Evidence-backed comparisons of source perspectives and observed adoption signals. Read the methodology
Which Builder, Operator, and Investor concerns the observed source mix emphasized—not a truth score.
Evidence, demonstrated adoption, hype gap, incentives, and confidence are assessed independently, each on its own current evidence. How these are measured.
Strong first-party technical evidence, single publisher
The technical core is unusually well evidenced for a single post: a named CVE, an exact tested build, a decompiled code excerpt showing the unvalidated Type.GetType() call and the 15-character branch, and a working malicious BDC model XML. What is missing is independent corroboration inside this cluster - the VulnCheck analysis and Microsoft's patch guidance are referenced but not supplied - and there is no data on affected population or exploitation.
Exploit knowledge public, field impact unmeasured
Adoption here is diffusion of usable exploitation knowledge, and that is real: coordinated disclosure on August 11 followed by an unplanned third-party publication and two independently documented exploitation paths by August 24. But the cluster contains no exploitation-in-the-wild telemetry, no count of exposed or unpatched SharePoint servers, and no patch-deployment data, so real-world impact cannot be scored higher.
Broadly aligned, slight urgency premium
Rapid7's framing is restrained and matches its own evidence: the technical claims are code-backed and the detection warning is stated as likelihood, not certainty. The small positive gap reflects that severity language (unauthenticated RCE via chaining, more gadget chains highly likely) runs ahead of any supplied evidence of active exploitation, patch gaps, or exposed population - and that the write-up's timing was driven by a disclosure race rather than a change in observed risk.
Vendor research under competitive pressure
The publisher is a commercial security vendor writing up a vulnerability it co-disclosed, and it says outright that it moved publication forward because a third party released details first - a visibility and credit incentive it discloses rather than hides. The post also positions its own exploitation route against a named rival analysis. Incentive is therefore evident and partly self-declared, but the technical content is verifiable code analysis rather than product promotion, and no product or service is pitched in the supplied text.
High on mechanism, low on scope and impact
Confidence in the mechanism and in the detection-coverage argument is high because both rest on code-level detail and an explicit vendor comparison. Confidence in anything beyond that - patch state, affected versions other than the tested build, exposure, exploitation activity - is low, since the cluster has a single publisher and no independent or vendor-advisory corroboration.
security
SharePoint flaw went from PoC to honeypot hits in a day, and Microsoft's advisory is still silent1 distinct publisher
build
ShieldBreak: a Defender-to-SYSTEM PoC that your last patch cycle did not stop1 distinct publisher
build
Microsoft is generating its detection test logs, and admitting what they do not prove1 distinct publisher
build
A researcher is timing zero-days to Patch Tuesday, and the monthly cadence has no reply1 distinct publisher
Distinct publishers with included, body-backed reporting in this cluster.
1 article · August 24, 2026