Build1 distinct publisher3 min readPublished
Attackers are forging tokens SharePoint accepts, then enumerating management APIs and probing Business Connectivity Services for the execution sink. BleepingComputer reports nobody has seen that last step land.
The Engineer · Build desk

Compiled by The EngineerSomething wrong?How this is made
Token validation is where a server decides whether a signature and a bag of claims deserve to be believed. CVE-2026-55040 is described as a flaw in exactly that check for SharePoint's JWTs, and the result is that an unauthenticated caller can act as a site user or administrator [2]. Nothing downstream is confused. The authorization code answers correctly for the principal it was handed, and it permits the API operations that principal is entitled to [6]. That is the mechanical reason the source says this needs no user interaction and looks unremarkable from regular SharePoint screens [7].
An identity is not an execution primitive, which is why the observed traffic keeps going. After the bypass the attacker enumerates management functions [3], then hunts for the CVE-2026-63520 sink in Business Connectivity Services and the Business Data Catalog [4]. The chain has a seam, and the source names three conditions across it: a server unpatched for both CVEs, network reachability from attacker to target, and BCS or BDC still reachable once authentication is out of the way [10].
Honeypots recorded the bypass, the enumeration and the probing, and did not record code execution [5]. That reaches the second of the three confirmation stages the write-up defines, with host-level execution unverified in public data [19]. Read the absence narrowly. Honeypots are instrumented to be interesting rather than to be representative of your patch level, so "no execution observed" describes what those sensors caught, not the reliability of the sink. What would upgrade the picture is host telemetry: child processes under w3wp, PowerShell or cmd, web shells, file writes, new scheduled tasks or service changes [9].
Patch order is the decision worth getting right. Shipping only Microsoft's 63520 update closes the road to code execution and leaves the unauthenticated administrator-equivalent API access sitting where it was [18]. Document access follows from that position alone; the credential and internal-connection outcomes are the ones the source marks as conditional on a successful chain and unconfirmed by the honeypot data [16].
In my context the network control goes first, because restricting internet exposure and BCS surfaces, or blocking post-bypass management calls at a WAF, lands in minutes without a maintenance window while the updates move through change control behind it [11]. Detection is the expensive part. The available signals are abnormal JWTs, management API enumeration from unauthenticated sources and continuous probes to the Business Data Catalog [8], and turning those into a verdict means matching request subjects against Entra or AD logins to find privileged operations with no corresponding sign-in [12]. That is a join across two systems most teams have not built. If execution does get confirmed on a host, the bill is isolation plus rotation of SharePoint, IIS and service account credentials [17].
Ranked by verification strength, evidence, and original report placement.
BleepingComputer reported on 2026-08-26, under the headline "Hackers target Microsoft SharePoint RCE chain with PoC exploit", that attackers are targeting a Microsoft SharePoint Server chain of CVE-2026-55040 and CVE-2026-63520.
Honeypots observed the JWT bypass, enumeration and probing, but did not observe code execution.
The attack may appear as abnormal JWTs, management API enumeration from unauthenticated sources, and continuous probes to the Business Data Catalog.
Recommended mitigations: apply the relevant Microsoft security updates; stop direct internet exposure and restrict management surfaces and BCS; block management operations after authentication bypass using applications, WAFs or network controls.
Containment guidance: apply updates and restrict unnecessary internet exposure and BCS functions, and isolate hosts and rotate SharePoint / IIS / service account credentials when RCE is confirmed.
An unauthenticated attacker exploits the JWT token validation flaw in CVE-2026-55040 to act as a SharePoint site user or administrator.
Distinct publishers with included, body-backed reporting in this cluster.
dev.to
1 article · August 27, 2026
Follow any of these and your For You feed starts watching them — no settings page required.
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
A Commerce Cloud RCE chain reached a honeypot three days after the patch shipped1 distinct publisher
build
A UDP packet is now enough: IKEEXT RCE moves from patch queue to fire drill1 distinct publisher
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.
Staged, self-limiting telemetry from a single retold report
The chain is described with concrete, checkable stages and the source explicitly bounds what was observed: honeypot probes and application-level bypass yes, host-level execution no. That self-limiting discipline plus a defined three-stage confirmation model is stronger than typical exploit-hype reporting. It is capped by the cluster containing one item from an aggregator restating BleepingComputer, with the underlying Rapid7, VulnCheck, Microsoft and Shadowserver material only referenced, and no affected-build or patch-level detail supplied.
Real probing at scale, execution stage unreached
Attacker-side uptake is documented: PoCs for both CVEs went public within two weeks, honeypots logged the chain being attempted the day after the second PoC, and 8,700+ internet-exposed SharePoint servers form the reachable surface. What is absent is any confirmed successful exploitation, any victim count, and any evidence about how many exposed servers are unpatched, so this reads as active reconnaissance rather than a realised campaign.
Headline promises RCE the body never confirms
The framing carried into this cluster - 'Hackers target Microsoft SharePoint RCE chain with PoC exploit', severity High - invites readers to assume code execution, while the body states three times that execution was never observed and that Microsoft had not listed the sink CVE as actively exploited. The gap is modest rather than large because the same item supplies the corrective explicitly and separates confirmed from contingent impact.
Attention-shaped framing, no product being sold
The visible incentive is editorial: a security-news headline and a High severity tag reward urgency, and the aggregator republishing it in a defender-playbook format inherits that framing. Working against distortion, the item sells nothing, names no product of its own, and volunteers the limits of the evidence. Vendor-linked analyses from Rapid7 and VulnCheck are cited but are not the authoring voice in this cluster, so their commercial interest reaches the story only indirectly.
Coherent single-source account, no corroboration in cluster
Internal consistency is high and the dated timeline is specific, which supports moderate confidence in what is asserted. But the cluster is one publisher, one item, and secondary to both the original report and the honeypot dataset, with no affected-version list and no independent confirmation available here, so confidence stays below the midpoint-plus range.