CVE Tools
Back to blog

SharePoint's quiet 9.1: an unauthenticated auth-bypass that unlocks a still-unpatched RCE (CVE-2026-55040)

A JWT token-validation bypass in on-prem SharePoint - no KEV, no public PoC, but a Pwn2Own-grade exploit and the front half of an unauthenticated-RCE chain

SharePoint's quiet 9.1: an unauthenticated auth-bypass that unlocks a still-unpatched RCE (CVE-2026-55040). A JWT token-validation bypass in on-prem SharePoint - no KEV, no public PoC, but a Pwn2Own-g
SharePoint's quiet 9.1: an unauthenticated auth-bypass that unlocks a still-unpatched RCE (CVE-2026-55040). A JWT token-validation bypass in on-prem SharePoint - no KEV, no public PoC, but a Pwn2Own-g

Buried in Microsoft's record July 2026 Patch Tuesday - roughly 570 CVEs in a single release - is a SharePoint bug that looks quiet on every dashboard and is anything but. It carries no KEV entry, no public proof-of-concept, and a low EPSS score, the trio that normally files a bug under do it next cycle. That read would be a mistake. The flaw is a security-feature bypass in SharePoint's token-authentication pipeline (CWE-1390, weak authentication): the control that ties a request to a validated identity can be defeated, so an anonymous attacker on the network can present a forged JSON Web Token the server trusts and become a chosen user. It was reported by Rapid7's Stephen Fewer as a Pwn2Own Berlin entry, and its real danger is architectural - it is the key that unlocks a separate, still-unpatched SharePoint RCE.

What the flaw actually is

On-prem SharePoint authenticates requests with signed JSON Web Tokens (JWTs). Rapid7 - who found the bug - describes "several issues in the JWT token validation pipeline" that let a remote, unauthenticated attacker present a token the server accepts and thereby assume the identity of any SharePoint site user, up to a farm administrator. That is precisely what **CWE-1390, weak authentication, names: the defeated "security feature" is the token check that should bind a request to a real, authorized principal. The one precondition is that the attacker must already know a valid target identity - an Active Directory SID or a User Principal Name** (the email-style login) - and Rapid7's proof-of-concept solves that operationally by enumerating SIDs to discover real users first, then forging a token to impersonate one.

Why "no public exploit" isn't "low risk"

As of July 21, 2026 the quiet signals are real and we should state them plainly: the bug is not in CISA's KEV catalog, there is no public PoC or Nuclei template (we checked GitHub code search and the ProjectDiscovery templates), and EPSS sits near 0.7%. But none of that means the bug is hard to weaponize. A finished, reliable Pwn2Own-grade exploit already exists - Rapid7 built it and agreed to Microsoft's standard ~30-day hold on technical details, so a public write-up and PoC are expected around mid-August 2026, most likely alongside Microsoft patching the chained RCE. "No GitHub PoC today" is an embargo artifact, not a difficulty rating. Microsoft's own exploitability index rates the flaw "Exploitation More Likely."

SignalValueWhat it tells you
CVSS base9.1 (Critical)Unauthenticated network identity bypass - the score is not the soft part
AuthenticationNone requiredAnyone who can reach the server (plus a known target SID/UPN) can try it
CISA KEVNot listed (as of 2026-07-21)No confirmed in-the-wild use - yet
EPSS~0.7%Reflects no public exploit today, not real-world difficulty
Private exploitYes - Pwn2Own-grade, embargoedDetails/PoC expected ~mid-August 2026
Microsoft assessmentExploitation More LikelyMicrosoft's own forward-looking flag
Exploited siblingsCVE-2026-56164, CVE-2026-58644 (on KEV)The surrounding SharePoint cluster is under live attack

The exploitation chain

The reason a "bypass" earns a 9.1 is what it connects to. On its own the flaw buys identity impersonation - powerful, but not server takeover. Chained with a second bug, it becomes something worse. Rapid7 is explicit that the JWT bypass, wired to a separate remote-code-execution vulnerability, yields unauthenticated RCE - and that the RCE half was still unpatched at disclosure, expected in the August 2026 cycle. That is the 2025 ToolShell pattern exactly: an auth/bypass primitive removes the login requirement guarding an otherwise authenticated-only deserialization RCE. The crucial defender's detail is the bright side of the same fact - patching this bug alone severs the chain, before the RCE is even public. The diagram traces the path and marks where to break it.

CVE-2026-55040 - SharePoint JWT auth-bypass -> unauthenticated RCE chain

  1. JWT auth bypass (CWE-1390) - unauth, CVSS 9.1 — The starting primitive: flaws in SharePoint's JWT validation let an unauthenticated attacker forge a token the server trusts. No login, no click.
  2. Find internet-facing on-prem SharePoint — Enumerate exposed 2016/2019/Subscription-Edition farms via default paths (/_layouts/15/, /_vti_bin/, /_api/) or the MicrosoftSharePointTeamServices header. SharePoint Online is not affected.
  3. Enumerate a target identity (SID / UPN) — The bypass needs a valid target. Rapid7's PoC enumerates Active Directory SIDs to discover real users and admins to impersonate.
  4. Forge JWT -> impersonate user/admin — This is CVE-2026-55040 itself: present a forged token the server accepts and assume the chosen identity - unauthenticated, over the network.
  5. SharePoint patched to fixed build? — Farm build at/above the July 2026 fixed build AND PSConfig has run? If yes, the bypass fails here and everything below is unreachable.
  6. Data compromise as impersonated admin — With impersonation alone (C:H/I:H): read every user's documents, alter content, reach admin surfaces - all inside SharePoint's scope. No code execution yet.
  7. Chain to deserialization RCE (embargoed sibling) — Impersonation removes the auth precondition guarding an authenticated-only deserialization RCE (Rapid7's still-unpatched partner, ~Aug 2026) -> unauthenticated RCE.
  8. Web shell in LAYOUTS + steal machine keys — Post-exploitation (ToolShell playbook): drop an .aspx web shell under LAYOUTS, exfiltrate ASP.NET ValidationKey/DecryptionKey to forge __VIEWSTATE tokens - persistence that survives a patch.
  9. Durable foothold / ransomware / espionage — Attacker retains access after the CVE is patched, until machine keys are rotated and shells removed. ToolShell precedent: China-nexus espionage and Warlock ransomware.
  10. PREVENT: keep farms off the raw internet — Shrinking reachability removes the attacker's first step. Front SharePoint with an authenticating reverse proxy; block external access to Central Administration.
  11. PATCH (breaks the chain): July 2026 update + PSConfig — Install the July 2026 CU for your SKU and run the Products Configuration Wizard. This severs the chain at the bypass - before the RCE half is public.
  12. CONTAIN: hunt, then rotate machine keys + iisreset — Because persistence rides on stolen keys, patching alone isn't enough on a previously-exposed farm. Hunt first, then rotate ASP.NET machine keys and restart IIS.

Am I affected?

This is an on-premises bug. SharePoint Online (Microsoft 365) is not affected. If you run SharePoint Server 2016, 2019, or Subscription Edition, you're in scope until you're on the July 2026 build. Confirm the farm build with (Get-SPFarm).BuildVersion and cross-check Get-SPProduct -Local - a common trap is a Cumulative Update that's installed but never finished its config-database upgrade because PSConfig wasn't run, leaving the farm reporting an old, still-vulnerable build.

ProductJuly 2026 KB(s)Fixed build (at or above)
SharePoint Server Subscription EditionKB500288216.0.19725.20434
SharePoint Server 2019KB5002883 + KB500288516.0.10417.20175
SharePoint Enterprise Server 2016KB5002891 + KB500289216.0.5561.1001

The timeline - and the clock that hasn't struck yet

The flaw sits inside a genuinely active SharePoint moment. Its siblings CVE-2026-56164 and CVE-2026-58644 are already exploited and on CISA's KEV list; this one is not. The dates that matter most are still ahead - the embargo lift and the second patch.

CVE-2026-55040 - disclosure, cluster, and the embargo clock

  1. ToolShell wave begins
    Mass exploitation of on-prem SharePoint (CVE-2025-53770 and friends), later tied to China-nexus actors and Warlock ransomware - the pattern this bug echoes.
    source
  2. Published & patched (July Patch Tuesday)
    Fixed in Microsoft's record ~570-CVE release; Rapid7 (Stephen Fewer) discloses the JWT bypass and agrees to a ~30-day hold on details. SharePoint 2016/2019 reach end of extended support.
    source
  3. Sibling CVE-2026-58644 added to CISA KEV
    A SharePoint deserialization RCE from the same release is confirmed exploited - the surrounding cluster is under live attack. CVE-2026-55040 is not added.
    source
  4. Embargo lifts; RCE half expected to patch
    Rapid7's ~30-day window closes: technical details and PoC expected, most likely alongside Microsoft patching the chained RCE in the August cycle.
    source

Detection & hunting

There is no CVE-specific signature and there can't be one yet - the technical detail is embargoed, and the bug is a token forgery, not a noisy request pattern. So you hunt the behaviour an auth bypass enables, using the well-documented ToolShell playbook as the template. The single highest-value signal is success where there should be failure: requests to authenticated-only SharePoint endpoints (/_api/, /_vti_bin/, admin surfaces) that return 200/302 with no matching successful authentication in the ULS logs - especially actions attributed to privileged accounts from unfamiliar IPs. Make sure IIS logging captures the Referer and User-Agent fields, or the classic bypass tells are invisible.

ToolShell-pattern behavioural detections (adapted for CVE-2026-55040)2 rules
sigma ×2

No public signature exists for this bug - these are generic SharePoint-intrusion detections adapted from the 2025 ToolShell campaign. They catch what an auth bypass enables (unauthenticated reach to admin endpoints, web-shell drops in LAYOUTS), not the JWT forgery itself. Tune paths/fields and exclude patching windows before enabling.

sigmaSharePoint ToolPane.aspx access with spoofed SignOut.aspx referrer
The ToolShell trick of reaching an admin-only endpoint without auth via a forged SignOut.aspx referrer. IIS web-server logs with cs(Referer) and cs-uri-query fields.
title: SharePoint ToolPane.aspx Access with Spoofed SignOut.aspx Referrer
status: experimental
description: ToolShell-pattern auth bypass reaching an admin-only endpoint without auth. Adapted as a generic SharePoint SFB behaviour detection for CVE-2026-55040 (no 55040 signature exists).
logsource:
  category: webserver
  product: iis
detection:
  selection_method:
    cs-method: 'POST'
  selection_uri:
    cs-uri-stem|contains:
      - '/_layouts/15/ToolPane.aspx'
      - '/_layouts/16/ToolPane.aspx'
  selection_referrer:
    cs(Referer)|contains: '/_layouts/SignOut.aspx'
  condition: selection_method and selection_uri and selection_referrer
fields: [c-ip, cs-uri-query, cs(User-Agent), sc-status]
level: high
sigmaSuspicious .aspx creation in the SharePoint LAYOUTS directory
Web-shell drop (e.g. spinstall0.aspx) under LAYOUTS - the canonical SharePoint post-exploitation artifact if the bypass is chained to RCE. File-creation telemetry (Sysmon Event ID 11 or EDR) on SharePoint servers.
title: Suspicious ASPX File Creation in SharePoint LAYOUTS Directory
status: experimental
description: Web-shell drop (spinstall0.aspx etc.) under LAYOUTS - strong signal of any SharePoint auth/RCE compromise, including a chain from CVE-2026-55040.
logsource:
  category: file_event
  product: windows
detection:
  selection_path:
    TargetFilename|contains:
      - '\Web Server Extensions\15\TEMPLATE\LAYOUTS\'
      - '\Web Server Extensions\16\TEMPLATE\LAYOUTS\'
  selection_ext:
    TargetFilename|endswith: '.aspx'
  selection_proc:
    Image|endswith: ['\w3wp.exe', '\cmd.exe', '\powershell.exe']
  condition: selection_path and selection_ext and selection_proc
fields: [Image, TargetFilename, User]
falsepositives:
  - SharePoint CU install writes .aspx to LAYOUTS via msiexec/OWSTIMER - scope Image to w3wp.exe or exclude maintenance windows
level: high
  • Correlate IIS success against ULS auth: 200/302 on /_api/, /_vti_bin/, or admin endpoints with no matching successful sign-in is the closest thing to a bypass tell.
  • Hunt web shells: new .aspx files under the LAYOUTS directory or web-app roots, and suspicious w3wp.exe child processes spawning cmd.exe/powershell.exe with -EncodedCommand.
  • Assume-breach on keys: any sign of ASP.NET machine-key theft means forged __VIEWSTATE tokens are possible - rotate keys after hunting.
  • Patch state, not exploit: in Microsoft Defender, DeviceTvmSoftwareVulnerabilities | where CveId == "CVE-2026-55040" lists hosts still missing the fix.

What to do now

  1. Inventory every on-prem SharePoint farm and read its build - internet-facing ones first.
  2. Patch to the July 14, 2026 update for your SKU and run PSConfig - the fix isn't active until the configuration wizard completes. This also breaks the RCE chain before its second half is public.
  3. Harden while you patch: enable AMSI Full-mode body scanning, block external access to Central Administration, and keep farms off the raw internet.
  4. Pre-stage detections for the mid-August details drop - deploy the ToolShell-pattern hunts now rather than waiting for a public PoC.
  5. Plan the 2016/2019 migration to Subscription Edition - those SKUs are now out of extended support and may not get the August RCE fix.

FAQ

Is CVE-2026-55040 being exploited in the wild?
Not as of July 21, 2026 - it is not on CISA's KEV list and there is no confirmed in-the-wild use or public exploit. But a working Pwn2Own-grade exploit exists privately at Rapid7 under a ~30-day disclosure hold, Microsoft rates it "Exploitation More Likely," and its SharePoint siblings CVE-2026-56164 and CVE-2026-58644 are already exploited and KEV-listed. Treat it as patch-now.
If there's no public exploit, why is it urgent?
Because "no public exploit" is an embargo artifact, not a difficulty rating - the exploit is finished, just not published, with details expected around mid-August. And because patching this bypass now severs an unauthenticated-RCE chain whose second half (a separate SharePoint RCE) is still unpatched, expected in August. You get to break the chain before it's fully public.
I use SharePoint Online (Microsoft 365). Am I affected?
No. This is an on-premises SharePoint Server vulnerability - 2016, 2019, and Subscription Edition. SharePoint Online is not affected.
Is patching enough?
Patch and run PSConfig first - that's the real fix and it breaks the chain. But if a farm was internet-exposed, hunt for compromise and then rotate the ASP.NET machine keys and restart IIS, because the surrounding SharePoint campaigns steal those keys to forge tokens and persist even after a patch.

Sources