On August 18, 2026, CISA added CVE-2026-55040 to its Known Exploited Vulnerabilities catalog after attackers began mass-scanning and hitting unpatched on-prem SharePoint servers within hours of Rapid7 publishing proof-of-concept exploit code. This is not a phishing story or a credential-stuffing story — it’s a pre-auth token forgery bug that lets an anonymous attacker walk in as a site administrator.

What’s actually broken

CVE-2026-55040 (CVSS 9.1) lives inside the JWT validation pipeline used by SharePoint’s service-to-service (S2S) bearer token handling — specifically two internal classes, SPJsonWebSecurityTokenHandlerV2 and SPJsonWebSecurityBaseTokenHandlerV2. Rapid7 researcher Stephen Fewer (who found the flaw at Pwn2Own Berlin) chained four separate weaknesses in that pipeline:

  1. The outer JWT can declare alg: none, so the outer wrapper needs no signature at all.
  2. An inner “actor token” carries an x5t header pointing at SharePoint’s own STS signing certificate thumbprint — the server resolves and trusts a signing key without actually verifying the chain.
  3. Claims inside the forged token (user, site, role) are accepted without cross-checking against a real authenticated session.
  4. The forged token is then honored by SharePoint’s internal S2S trust as if it came from a legitimate farm service, letting the attacker impersonate any site user — including farm administrators.

The result: no credentials, no MFA prompt, no user interaction. Just a crafted Authorization: Bearer <forged-jwt> header sent to a vulnerable Server 2016/2019/Subscription Edition farm. SharePoint Online is not affected — this is an on-prem-only bug, patched by Microsoft on July 14, 2026. Anything internet-facing and unpatched has effectively been sitting exposed since the PoC dropped on August 11.

Post-auth, observed activity mirrors prior SharePoint auth-bypass campaigns (ToolShell-adjacent tradecraft): attackers use the forged admin session to drop a webshell under _layouts/15/ or LAYOUTS custom pages, harvest the farm’s MachineKey (ViewState signing/validation keys) for persistence, and spawn cmd.exe/powershell.exe from w3wp.exe.

Detecting the forged-token request (IIS / reverse proxy logs)

The alg: none header is the tell. Base64url-encoded, {"alg":"none"} is the literal string eyJhbGciOiJub25lIn0, and it will always appear as the first segment of the Authorization: Bearer value. This is cheap and reliable to catch at the WAF/IIS layer before it ever reaches application logic.

title: Possible CVE-2026-55040 SharePoint JWT alg-none Auth Bypass Attempt
id: 9d2c9f1a-6e3b-4b2a-8b0e-1a2e7c55d040
status: experimental
description: Detects an inbound Authorization Bearer JWT with an unsigned "alg":"none" header targeting an on-prem SharePoint server, consistent with CVE-2026-55040 exploitation.
references:
    - https://www.rapid7.com/blog/post/ra-microsoft-sharepoint-jwt-token-authentication-bypass-cve-2026-55040/
    - https://www.cisa.gov/news-events/alerts/2026/08/18/cisa-adds-four-known-exploited-vulnerabilities-catalog
logsource:
    category: webserver
    product: iis
detection:
    selection_header:
        cs-uri-stem|contains:
            - '/_vti_bin/'
            - '/_api/'
            - '/_layouts/15/'
        cs-Authorization|contains: 'Bearer eyJhbGciOiJub25lIn0'
    condition: selection_header
falsepositives:
    - None expected; alg:none JWTs have no legitimate use in SharePoint S2S auth
level: critical
tags:
    - attack.initial-access
    - attack.t1190
    - cve.2026.55040

If your reverse proxy or WAF doesn’t log the raw Authorization header value, at minimum alert on any request to /_vti_bin/client.svc, /_api/, or S2S token-consuming endpoints where the Authorization header is present but no corresponding successful ADFS/Windows-auth or Kerberos ticket event exists in the same window — that mismatch is the behavioral signature of a forged bearer token bypassing normal auth.

Hunting for post-exploitation (Sysmon / EDR)

Once impersonation succeeds, the attacker interacts with SharePoint through the IIS worker process. w3wp.exe spawning a shell is abnormal in virtually all SharePoint deployments:

title: Suspicious Child Process from SharePoint IIS Worker Process
id: 7b1e4a90-3f22-4e6d-9a5c-55040e2b9c11
status: experimental
description: Detects w3wp.exe (IIS worker process) spawning command interpreters or scripting engines, consistent with post-exploitation of a SharePoint auth bypass such as CVE-2026-55040.
logsource:
    category: process_creation
    product: windows
detection:
    selection_parent:
        ParentImage|endswith: '\w3wp.exe'
    selection_child:
        Image|endswith:
            - '\cmd.exe'
            - '\powershell.exe'
            - '\pwsh.exe'
            - '\csc.exe'
            - '\certutil.exe'
            - '\w3wp.exe'
    filter_known_app_pool:
        ParentCommandLine|contains: 'SharePoint - 80'  # tune to known legitimate app pools if any spawn child tools
    condition: selection_parent and selection_child and not filter_known_app_pool
falsepositives:
    - Rare SharePoint add-ins or admin tooling that legitimately shell out from the app pool
level: high
tags:
    - attack.execution
    - attack.t1059
    - attack.t1190

Hunting the MachineKey theft angle in Sentinel

If the farm’s ViewState MachineKey is exfiltrated post-compromise, expect anomalous stsadm/Set-SPSecurityTokenServiceConfig or registry/config file reads outside normal admin change windows. A quick KQL starting point against Windows Security + Sysmon-fed Sentinel data:

DeviceProcessEvents
| where FileName in~ ("cmd.exe", "powershell.exe", "pwsh.exe")
| where InitiatingProcessFileName =~ "w3wp.exe"
| where InitiatingProcessCommandLine has_any ("SharePoint", "OWSTIMER", "w3wp")
| project TimeGenerated, DeviceName, InitiatingProcessCommandLine, ProcessCommandLine, AccountName
| order by TimeGenerated desc

Pair this with a check for _layouts requests returning HTTP 200 for newly created .aspx files — a strong webshell-drop indicator in IIS logs following a successful bypass.

Action items

  • Patch to the July 14, 2026 cumulative update or later immediately if you run SharePoint Server 2016/2019/Subscription Edition on-prem.
  • If patching is delayed, restrict /_vti_bin/, /_api/, and S2S endpoints to internal networks only.
  • Rotate the farm’s MachineKey after patching if any exposure window existed — old keys remain valid for forged ViewState even post-patch.
  • Deploy the IIS and process-creation rules above now; both are low-noise and specific to this exploit chain.

Sources: Rapid7 Technical Analysis (CVE-2026-55040), CISA KEV Catalog Addition Aug 18, 2026, The Hacker News: Attackers Exploit SharePoint Authentication Bypass After Public PoC Release