CVE-2026-55040: critical SharePoint JWT authentication bypass — why the Rapid7 PoC triggered an exploitation wave and what it means for your on-prem

13 August 2026 10 min read 2093 words

CVE-2026-55040 (CVSS 9.1, Weak Authentication / CWE-1390) is a critical vulnerability in Microsoft SharePoint Server (Subscription Edition, 2019, 2016) that allows a remote, unauthenticated attacker to bypass authentication and perform operations as any user — including a farm administrator. The bug sits in the JWT validation pipeline of SharePoint; Microsoft addressed the vulnerability in Patch Tuesday July 2026 (severity raised from medium to critical on 14.07.2026), but the defining moment is what happened after the PoC went public.

On 11 August 2026, Stephen Fewer (Rapid7 Labs) published the full technical write-up and PoC code (previously demonstrated at Pwn2Own Berlin). On 12 August 2026, Defused confirmed active exploitation of the PoC in attacks against SharePoint honeypots, while Shadowserver pointed to >8,500 SharePoint servers exposed on the public internet. Microsoft has not yet flagged the flaw as „exploited in the wild" in CISA KEV (state as of 12.08.2026), but the pressure on patch management for organisations running on-prem SharePoint — especially those with M365 federation — is now clear. CERT Polska published communication 143/2026 precisely because of the PoC publication and the rising attack pressure.

For B2B firms and manufacturing: the priority is (1) confirm build version vs. Microsoft advisory and patch immediately, (2) scan farms for compromise indicators in the last 30 days (anomalous logins, JWT tokens without prior MFA flow, privilege escalation), (3) verify federation integrations (ADFS / Entra hybrid) — the bypass can be a pivot into M365.

Key facts

CVE-2026-55040 is a Weak Authentication flaw (CWE-1390) in Microsoft SharePoint Server — a bug in JWT validation enables remote, unauthenticated bypass of authentication and acting as any SharePoint user, including farm administrator. It affects only on-prem versions (Subscription Edition, 2019, 2016); SharePoint Online in M365 managed by Microsoft is not affected.
CVSS 9.1 (severity critical). Microsoft addressed it in Patch Tuesday July 2026 — severity raised from medium to critical on 14.07.2026, signalling an internal risk reassessment following Rapid7's report.
Discoverer: Stephen Fewer, Senior Principal Security Researcher at Rapid7 Labs. A two-CVE chain (including CVE-2026-55040) was demonstrated at Pwn2Own Berlin; the full technical write-up and PoC were published on 11 August 2026 in the official Rapid7 blog. CERT Polska published communication 143/2026 the next day (12.08.2026) because of the publication and the rising attack risk.
Active exploitation (state as of 12.08.2026): Defused honeypot telemetry confirmed — „Attackers are now using the @rapid7 POC for CVE-2026-55040 against our SharePoint honeypots" (12.08.2026). Shadowserver pointed to >8,500 SharePoint servers exposed online (global).
KEV status: Microsoft has not yet flagged the flaw as „exploited in the wild" in CISA KEV (state as of 12.08.2026), but CISA in a July 2026 alert indicated „Exploitation More Likely" for related CVEs in this product family (CVE-2026-58644 was added to KEV on 16.07.2026). Absence of a KEV entry does not equal safety — this is an unauthenticated flaw with a public PoC.
Risk chain: JWT bypass → impersonation of any SharePoint user (including admin) → access to documents, lists, workflows, farm settings → potential lateral movement to Microsoft 365 in organisations with federation (ADFS / Entra hybrid trust). Risk grows when SharePoint has Power Automate / Power Apps integrations with access to LOB data.
Sector: cross-sector, but the at-risk population concentrates in organisations keeping on-prem SharePoint for regulatory reasons (sensitive data, automotive Tier-1, medical, public institutions, government). Polish context: CERT Polska addressed its communication directly to organisations with SharePoint on-prem in PL.
Classification perspective: the flaw affects confidentiality and integrity; if successfully exploited on a farm holding personal data or IP, it falls within the scope of NIS2 Art. 21 (risk-mitigation measures) and Art. 23 (incident-handling procedures). Exact incident classification requires evaluation of your organisation — legal interpretation requires working with a law firm.

Decision table

Area	What we know	What it means for B2B / manufacturing	Recommended action 30 days	Recommended action 90 days
Unauthenticated JWT bypass	CVSS 9.1, public PoC 11.08.2026, active exploitation in honeypots 12.08.2026	Every internet-facing on-prem SharePoint farm is a potential target — the attack requires no account, no user interaction	Inventory on-prem SharePoint farms (including build version), validate vs. Microsoft July 2026 Patch Tuesday advisory	Implement a standing 72h SLA for CVE critical (CISA KEV benchmark) regardless of KEV status
Impersonation of any user	JWT bypass → any identity, including farm administrator	SharePoint logs do not always surface a compromise trail — the attacker „looks like" an authorised admin	Audit SharePoint logs (last 30 days) for: logins without MFA flow, privilege escalation, Farm Administrators group changes, unusual web service calls	Integrate SharePoint telemetry into SIEM (User Profile Service logs, SharePoint ULS, IIS), correlate with auth logs (ADFS / Entra ID)
Path to M365 (federation)	Organisations with ADFS / Entra hybrid trust: farm compromise = potential entry into M365	On-prem SharePoint is often overlooked in M365-first threat models — a classic blind spot	Audit SharePoint ↔ M365 federation trust, verify claim rules, review conditional access policies for on-prem farms	Migrate from ADFS to Entra ID cloud-only or hybrid with Phishing-Resistant MFA, eliminate legacy auth
Public PoC = attack wave	Rapid7 published full technical write-up and PoC code on 11.08.2026	Public PoC lowers the entry bar — exploitation no longer requires security researchers	Threat hunting using IoC from Rapid7 / Microsoft / CERT Polska (YARA, log signatures), scanning known webshell locations	Deploy deception / internal SharePoint honeypot farm for early detection of pre-exploit scanning
No CISA KEV entry	Microsoft has not flagged the flaw as „exploited in the wild" in KEV (state 12.08.2026)	No KEV entry does not mean no exploitation — Defused telemetry confirms it	Treat CVE-2026-55040 as KEV-equivalent in internal patch management SLA (72h) regardless of official status	Continuous monitoring: CISA KEV, CERT Polska, MSRC, Rapid7 research blog
NIS2/KSC lens	Flaw affects confidentiality + integrity; 24h/72h reporting	Essential/important entities with on-prem SharePoint: CSIRT NASK early-warning obligation upon confirmed exploitation	Verify reporting channel to CSIRT NASK, define critical incident template, escalate to board	Drill the scenario „SharePoint pre-auth RCE → M365 escalation" with IT + security + board

Perspective — Marcin Białczyk

— I do not have a public client case study on this topic yet; I will gladly describe a concrete deployment after the client consents. That said, below is the operational framework I use when assessing SharePoint on-prem exposure in the context of a JWT bypass.

Why this flaw is more serious than „just another RCE". Most headlines around SharePoint in 2026 have focused on CVE-2026-58644 (ToolShell, ransomware, IIS machine-key theft). CVE-2026-55040 operates in a different vector — unauthenticated JWT bypass — but in the same product family. The key difference: here there is no authentication phase to bypass, so there is no „failed login" log in the classical sense. The attacker presents a forged JWT and immediately acts as an administrator. For organisations that monitor only failed authentication, this flaw is practically invisible — until someone modifies the farm administrators list or pulls documents from SharePoint libraries.

Why the PoC publication changes everything — and quickly. The CVE-2026-55040 history shows a classic pattern: the researcher (Rapid7 Labs, Stephen Fewer) finds the flaw during Pwn2Own research, works with Microsoft on the patch, Microsoft addresses it on 14.07.2026 (raising severity from medium to critical). But the full PoC was published only on 11.08.2026 — a month after the patch. This is the standard „responsible disclosure" cycle, which gives defenders time, but also precisely measures attacker reaction time. By 12.08.2026 Defused honeypots already saw exploitation. This is the tempo in which patch management does not keep up with the threat landscape — organisations that did not patch in July no longer have a buffer.

What I would do in the first 30 days if I managed a SharePoint on-prem farm.

Build verification: check the build version of every on-prem SharePoint farm (Central Administration → Upgrade and Migration → Check upgrade status) and compare with the Microsoft advisory from Patch Tuesday July 2026. If a farm is not on the latest build — schedule a maintenance window ASAP, ideally in failover mode if the topology is active-passive.
Post-exploitation threat hunting: audit SharePoint logs (ULS, IIS, SharePoint audit logs) over the last 30 days for: logins without prior MFA flow, privilege escalation (added to the Farm Administrators group), Claims Providers modifications, new site collections with unusual templates, anomalies in SPSecurityTokenService.
Federation and lateral movement: if the farm is in a federation trust with Entra ID / ADFS — check ADFS logs for unusual token issuance (especially without prior MFA flow in Entra ID). Verify whether SharePoint has Power Platform integrations enabled (Power Automate, Power Apps) and which service principal accounts are in use.
Environmental signals: check whether SharePoint may have already been exploited — look for: anomalies in w3wp.exe, new .aspx files in TEMPLATE\LAYOUTS\15\, unusual activity in SPSecurityTokenService, dumps in c:\windows\temp. Use IoC from Rapid7 / Microsoft / CERT Polska as the baseline.
Backups: verify the offline + immutable backup procedure + test restore from a selected SharePoint farm (especially important because SharePoint has specific backup/restore requirements — it is not a regular file directory).

In 90 days — a continuity programme: shortening the patch management cycle to 72h for CVE critical (regardless of KEV status), SharePoint telemetry integration with SIEM, a SharePoint-specific threat hunting playbook, drill the scenario „pre-auth RCE → M365 escalation" with IT, security, and board. This is the scope in which CHORS NIS2/KSC Continuous Readiness has practical application for such clients — not as „certification", but as building operational continuity with real drills and evidence.

Frequently asked questions

Does CVE-2026-55040 affect SharePoint Online (Microsoft 365)?

No. The vulnerability only affects on-prem SharePoint Server (Subscription Edition, 2019, 2016). Microsoft 365 SharePoint Online managed by Microsoft is not affected. But hybrid integrations — Power Automate, Power Apps, on-prem data gateways, ADFS / Entra hybrid federation — are. It is worth verifying the data path between on-prem SharePoint and M365.

Does the July 2026 patch fully eliminate the risk?

Yes, if the farm was patched before 11.08.2026 (PoC publication date). If the farm was exploited earlier — the patch closes the vulnerability, but the consequences of compromise (stolen data, retained access, modified configurations) require a separate post-incident review. The absence of a „failed login" log does not mean no exploitation — this flaw succeeds on the first attempt.

How do I detect whether a farm was exploited?

Indicators: (a) ULS / IIS logins without prior MFA flow or without the typical request → token sequencing, (b) unauthorised changes to the Farm Administrators group, (c) new site collections or web applications created without a matching change ticket, (d) anomalies in SPSecurityTokenService (token issuance from unusual sources), (e) .aspx files in TEMPLATE\LAYOUTS\15\ directories outside the standard set. Recommendation: a threat hunting playbook based on IoC from Rapid7 / CERT Polska + YARA scanning.

Does this incident fall within NIS2/KSC scope?

Yes — the breach of confidentiality and integrity. Essential/important entities with on-prem SharePoint should consider early-warning reporting to CSIRT NASK within 24h of confirmed exploitation, in line with NIS2 Art. 23. Classification of a specific incident requires evaluation of your organisation (data scope, sector, scale) — legal interpretation requires working with a law firm. CERT Polska in communication 143/2026 highlights this vulnerability as significant for organisations in PL.

Is it worth deploying EDR on SharePoint servers?

From this incident's perspective — yes. A JWT bypass is hard to detect at SharePoint log level (no failed login, the token looks correct), but EDR with process monitoring (w3wp.exe, PowerShell spawn from SharePoint context) and File Integrity Monitoring on SharePoint directories improve the chance of detecting post-exploitation. Deploying EDR on SharePoint front-ends is a programme element in our CHORS NIS2/KSC Continuous Readiness.

How CHORS.NET helps

CHORS.NET supports the technical-operational side: passive exposure assessment, configuration verification, evidence packs and NIS2/KSC readiness support. See: Services, About CHORS.NET and Contact.

Boundaries and assumptions

We are not a 24/7 SOC and we do not guarantee detection of every incident. This article describes the mechanism and observations from publicly available sources (Rapid7, MSRC, CERT Polska, Shadowserver, Defused, CISA), and is not a guarantee for any specific environment.
We do not certify NIS2/KSC compliance — CHORS NIS2/KSC Readiness is a review and continuity-building service (BCP/DR, governance, exercises), not a certification audit. We do not issue a standalone legal opinion.
Results reflect the state at the time of this article (2026-08-12). Microsoft, Rapid7, CISA, and CERT Polska publish updates — including any change in KEV status; we recommend tracking these sources.
For legal interpretation (including incident classification, reporting, 24h/72h thresholds) CHORS works with law firms.
The material is informational and technical; it is not legal advice.

Precyzyjna wiedza
o ciemnych systemach.