CVE-2026-55040: SharePoint JWT Auth Bypass Now in CISA KEV

This week in our InSEKurity of the Week series: an authentication bypass in Microsoft SharePoint Server that requires no credentials, no user interaction, and no clever timing — just a single HTTP request carrying a token the server should never have accepted. CVE-2026-55040 is not one bug. It is four independent failures in the same JWT validation pipeline, stacked so precisely that each one covers for the next: signature verification is switched off, the signing key is resolved from an attacker-controlled header, an unregistered issuer is accepted with an apologetic log line, and the final signature check verifies only that the signature field is not empty. Chain them and you can mint a token for any user on the farm, including a site collection administrator.

Microsoft patched it quietly on July 14, 2026 — rated CVSS 9.1 and described in the anodyne language of the Security Update Guide as “bypass a security feature over a network.” It stayed quiet for four weeks. Then Rapid7, who found it, published a full technical write-up and a working proof-of-concept on August 11. Exploitation attempts hit honeypots the next day. On August 18 CISA added it to the Known Exploited Vulnerabilities catalog with a three-day remediation deadline. That is the timeline that makes this week’s entry worth your attention: the patch had been available for 35 days before anyone was in a hurry, and the thing that changed the risk was not a new bug — it was a blog post.

There is a second half to this story, and it is the part most coverage has skipped. CVE-2026-55040 was never meant to be the whole exploit. It is the front half of a Pwn2Own Berlin 2026 chain, and its partner — CVE-2026-63520, an unsafe .NET type instantiation in Business Connectivity Services — was patched a month later, on August 11, 2026. Together they are unauthenticated remote code execution on a SharePoint farm. If you patched in July and stopped, you closed the door and left the window open.

🚨 Summary

CVE ID: CVE-2026-55040
CVSS 3.1 Score: 9.1 Critical (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N)
CWE: CWE-1390: Weak Authentication
Affected Software: SharePoint Server Subscription Edition, SharePoint Server 2019, SharePoint Enterprise Server 2016. SharePoint Online (Microsoft 365) is not affected.
Attack Vector: Network — a single HTTP request with a forged Authorization: Bearer header
Authentication Required: None
Impact: Full impersonation of any SharePoint site user or site collection administrator; read and write access to site content; a ready-made front end for an authenticated RCE
Patch Status: Available since 2026-07-14 (July Patch Tuesday)
Published: NVD record published 2026-07-14, last modified 2026-08-19
Exploitation Status: Actively exploited. Honeypot hits from 2026-08-12, one day after the public PoC
CISA KEV: Listed — added 2026-08-18, remediation due 2026-08-21, ransomware use recorded as Unknown
Reported by: Stephen Fewer, Rapid7 — disclosed to Microsoft 2026-05-18 as part of a Pwn2Own Berlin 2026 entry
Chain partner: CVE-2026-63520 (CVSS 8.1, RCE) — patched separately on 2026-08-11

🖥️ What is Microsoft SharePoint Server?

Microsoft SharePoint Server is the on-premises version of SharePoint: a document management, collaboration and intranet platform that runs on Windows Server and IIS, backed by SQL Server. It is where organizations put the documents that are too sensitive, too regulated, or too integrated with internal systems to move to the cloud — which is precisely why the on-premises product still exists in 2026 while SharePoint Online handles everything else.

That selection effect matters for this CVE. A SharePoint farm is rarely a low-value target. It typically holds contracts, HR records, board material, engineering documentation, and the internal wiki that explains how everything else is configured. It is also deeply integrated: SharePoint holds service account credentials, talks to Active Directory, indexes file shares through its search crawler, and frequently runs with a service account whose privileges were granted years ago by someone who has since left. Compromising a SharePoint farm is rarely the end of an intrusion — it is a very good beginning.

It is also unusually exposed for something so valuable. Because SharePoint is how remote staff and external partners reach internal documents, farms are routinely published to the internet. Shadowserver tracks close to 10,000 internet-facing Microsoft SharePoint servers. And SharePoint has become one of the most reliably attacked enterprise products of the decade: CVE-2026-55040 is the fifth SharePoint flaw known to be exploited in 2026 alone, alongside CVE-2026-32201, CVE-2026-45659, CVE-2026-50522, CVE-2026-56164 and CVE-2026-58644. Attackers have learned that the on-premises install base is large, valuable, slow to patch, and often internet-reachable.

Typical Use Cases

Corporate intranets and team sites — the default landing page for tens of thousands of employees
Document management and records retention — versioned, permissioned storage for contracts, policies and regulated records
Enterprise search — a crawler that indexes SharePoint content and connected file shares, making the search index a map of the organization’s data
Business Connectivity Services (BCS) — surfacing external systems (SQL, SAP, line-of-business APIs) as SharePoint lists. This is where the chain partner CVE-2026-63520 lives.
Extranets and partner portals — the reason so many farms are published to the internet in the first place
Workflow and forms platforms — long-lived business processes that make farms extremely difficult to decommission

🔍 Technical Analysis

Vulnerability Description

SharePoint Server supports server-to-server (S2S) authentication, an OAuth 2.0-based protocol that lets trusted servers — another SharePoint farm, Exchange Server, Workflow Manager — request resources on behalf of a user. The mechanism is a nested JWT: an outer token proves which server is asking, and an embedded actor token carries the user identity being asserted. Trust is anchored in a certificate: you register a peer server’s Security Token Service (STS) with New-SPTrustedSecurityTokenIssuer, pointing at its JSON metadata endpoint, and from then on SharePoint will accept tokens signed by that STS.

The security of the whole design rests on one thing: the signatures must actually be verified. CVE-2026-55040 is the discovery that, in the SPJsonWebSecurityTokenHandlerV2 code path, they are not — in four different ways. An unauthenticated attacker can construct a nested token that asserts any identity they like, sign nothing, and have SharePoint accept it as a valid S2S request. SharePoint then processes the request as that user.

Microsoft’s own description — “Weak authentication in Microsoft Office SharePoint allows an unauthorized attacker to bypass a security feature over a network” — is technically accurate and radically undersells what happens next. The CVSS vector tells the more honest story: AV:N/AC:L/PR:N/UI:N — network, low complexity, no privileges, no user interaction — with high confidentiality and integrity impact.

Root Cause Analysis

Rapid7’s analysis identifies four distinct weaknesses, all in the same validation pipeline. Individually, any one of them might be survivable. Together they remove every cryptographic check in the chain.

Signature verification is explicitly disabled. SPJsonWebSecurityTokenHandlerV2.ValidateToken() sets RequireSignedTokens = false. This is the single most consequential line: it means the handler accepts a token whose header declares "alg": "none". The outer token’s signature is never examined, because as far as the handler is concerned there is not supposed to be one.
The signing key is resolved from an attacker-controlled header. GetSigningKeyIdentifier() reads the x5t field — an X.509 certificate thumbprint — straight out of the actor token’s header and hands it to SPIssuerTokenResolver.TryResolveToken(), which dutifully resolves it to a signing key. At no point in this sequence is the actor token’s own signature validated against that key. The attacker chooses which key SharePoint looks up, and looking it up is mistaken for verifying against it.

This weakness is only trivially exploitable because of a design decision elsewhere: SharePoint publishes its own STS signing certificate at an unauthenticated endpoint. GET /_layouts/15/metadata/json/1 — the documented JSON metadata endpoint used to establish S2S trust — returns the certificate to anyone who asks, thumbprint included. The attacker does not need to guess or steal the x5t value. The server hands it over.
An unregistered issuer is accepted anyway. The ValidateIssuer() overload in this path calls GetProviderBySigningCertificate() to find the registered STS matching the certificate. When that lookup returns null — that is, when no trusted issuer matches — the method does not reject the token. It accepts it, and records the decision in the ULS log:

ValidateTokenIssuer accepted Issuer because no registered STS matches

This is a fail-open on the exact condition the function exists to detect. It is also, as we will use below, an excellent detection signature.
The final signature “check” is not cryptographic. GetTokenSignature() verifies that the signature component is a non-empty string. Not that it is valid. Not that it is well-formed base64. Just that something is there. A signature of AAAA satisfies it.

The structural mistake underneath all four is that the code path treats the outer and inner tokens differently and trusts each on the strength of the other. The outer token is exempt from signature checks because the nested actor token is presumed to carry the cryptographic proof; the actor token is never verified because resolving its key is mistaken for validating it. Neither is checked, and each one’s exemption is justified by the other.

Attack Vector

The full flow requires two HTTP requests — one to collect the certificate thumbprint, one to use it.

Attacker                                  SharePoint Server
   |                                             |
   |  (1) GET /_layouts/15/metadata/json/1       |
   |      no authentication required             |
   +-------------------------------------------->|
   |<--------------------------------------------+
   |      STS signing certificate, incl. x5t thumbprint
   |                                             |
   |  (2) Build a nested token:                  |
   |      outer header  { "alg": "none" }             <-- Weakness 1
   |      actor header  { "alg": "RS256",
   |                      "x5t": "<thumbprint>" }     <-- Weakness 2
   |      actor claims  identity = SID or UPN of target user
   |      signature     "AAAA"                        <-- Weakness 4
   |                                             |
   |  (3) GET /_api/web/currentuser               |
   |      Authorization: Bearer <forged token>   |
   +-------------------------------------------->|
   |                                             |
   |    RequireSignedTokens = false   -> outer signature not checked
   |    GetSigningKeyIdentifier()     -> resolves the attacker's x5t
   |    ValidateIssuer()              -> no registered STS, accept    <-- Weakness 3
   |    GetTokenSignature()           -> string is non-empty, accept
   |                                             |
   |<--------------------------------------------+
   |      200 OK -- request processed as the impersonated user

Step 1 — harvest the thumbprint. An unauthenticated GET against the metadata endpoint returns the farm’s STS signing certificate. This is documented, intended behaviour for establishing S2S trust; it becomes a problem only because of weakness 2. You can confirm your own farm exposes it — this is a plain read of a public endpoint on a server you own:

# Confirm the S2S metadata endpoint is reachable and see what it returns.
# -s silent, -k tolerate a self-signed/internal CA cert, -o discard the body,
# -w print only the HTTP status code.
curl -sk -o /dev/null -w 'HTTP %{http_code}\n' \
  https://sharepoint.example.com/_layouts/15/metadata/json/1

# To inspect the JSON itself (this is the certificate an attacker reads):
curl -sk https://sharepoint.example.com/_layouts/15/metadata/json/1

A 200 here is normal and expected — it is not by itself evidence of a vulnerability or a compromise. The point is that on an unpatched farm, this response is the first half of an exploit, and it costs the attacker nothing.

Step 2 — forge the token. The token structure below is illustrative — it shows the shape of the claims Rapid7 documented, not a working exploit:

// ILLUSTRATIVE ONLY -- structure of the forged nested token, decoded.
// This is NOT a functional exploit and will not authenticate as written.
{
  "outer_header":  { "alg": "none", "typ": "JWT" },
  "outer_payload": {
    "actortoken": "<base64url actor token, see below>"
  },
  "outer_signature": "",

  "actor_header":  { "alg": "RS256", "x5t": "<thumbprint from step 1>" },
  "actor_payload": {
    "nameid": "<SID or UPN of the user to impersonate>",
    "aud":    "<realm GUID of the target farm>"
  },
  "actor_signature": "AAAA"
}

Step 3 — know who to impersonate. This is the one genuine prerequisite, and it is the reason AC:L is arguably generous. Impersonation requires naming a real identity: a Windows SID or a UPN. Rapid7 notes that an attacker obtains these through Active Directory SID enumeration or UPN discovery — and the public PoC automates it, iterating RIDs (up to 10000 by default) against the target’s domain controller to find accounts and locate site administrators. The PoC’s documented flags make the workflow explicit:

# ILLUSTRATIVE -- the flags documented in Rapid7's public PoC repository
# (github.com/sfewer-r7/CVE-2026-55040). Reproduced to show what the
# attacker automates. Only ever run against systems you are authorized to test.

--target      target IP; auto-discovers the remaining parameters
--host        SharePoint hostname (for the Host header / realm resolution)
--x5t         STS signing certificate thumbprint (from the metadata endpoint)
--realm       SharePoint realm GUID
--sid         Windows SID to assert as the identity
--upn         User Principal Name, e.g. administrator@domain.local
--auto-upn    derive the UPN from the server's HTTPS certificate
--username    username to use for the derived UPN (default: administrator)
--rid         a specific RID (skips enumeration)
--max-rid     highest RID to iterate (default: 10000)
--domain-ip   domain controller IP, used for SMB-based discovery
--port/--http non-standard port / plaintext HTTP

Note the significance of --auto-upn and --max-rid: the attacker does not need prior knowledge of your environment. They derive the domain from the TLS certificate, then brute-force RIDs until they find an administrator. The “attacker must know the target identity” prerequisite is a speed bump, not a control.

Step 4 — act as that user. The forged token is sent as a normal bearer credential to any authenticated surface. Rapid7’s analysis and PoC exercise /_api/web/currentuser (confirming which identity the server believes it is talking to), /_api/contextinfo (retrieving the form digest needed for write operations), and /_vti_bin/sites.asmx. From there, the attacker has whatever SharePoint access the impersonated user has.

The Full Chain: Bypass Plus RCE

CVE-2026-55040 was never the endgame. It is half of a two-bug chain that Rapid7 Labs built as a Pwn2Own Berlin 2026 entry, and the reason the auth bypass matters so much more than “impersonate a user” suggests:

  CVE-2026-55040                        CVE-2026-63520
  Weak authentication (CWE-1390)        Improper input validation (CWE-20)
  CVSS 9.1                              CVSS 8.1
  patched 2026-07-14                    patched 2026-08-11
        |                                       |
        v                                       v
  +--------------------+                +----------------------+
  | forge a JWT,       |  authenticated | unsafe .NET type     |
  | act as any user    | ---session---> | instantiation in     |
  | (no credentials)   |                | Business Connectivity|
  +--------------------+                | Services            |
                                        +----------------------+
                                                 |
                                                 v
                                     arbitrary code execution as the
                                     SharePoint service account

CVE-2026-63520 (CVSS 8.1, AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:H/E:U/RL:O/RC:C, CWE-20) is an unsafe .NET type instantiation reached through Business Connectivity Services. On its own it is an authenticated bug of limited interest. Bolted behind CVE-2026-55040, the pair is unauthenticated RCE against every supported SharePoint version, executing as the SharePoint service account.

The operationally important detail: the two halves were patched a month apart. The bypass went out on July 14; the RCE went out on August 11. A farm patched in July and not since is still missing the second half.

Microsoft’s August update also hardened the affected feature directly. Per KB5002893, the August 2026 update disables file-backed Business Data Connectivity (BDC) model import by default, with a new Enable-BdcmFileImport cmdlet available to switch it back on per site collection. Treat that cmdlet as a decision, not a convenience — see the mitigation section.

Exploitation in the Wild

The exploitation curve here is driven entirely by public information release, not by the patch:

2026-07-14 — Patch ships. Microsoft’s advisory language is deliberately vague; no technical detail is public.
2026-07-19 — KEVIntel records the first exploitation attempt. A single probe, four weeks before the write-up. Someone was working from the patch diff.
2026-07-14 to 2026-08-11 — Near silence. 12 attempts total are recorded across this entire period.
2026-08-11 — Rapid7 publishes the technical analysis and a working PoC.
2026-08-12 — Defused reports its honeypots being attacked, explicitly using Rapid7’s PoC. 8 of the 12 total recorded attempts fall on August 12-13 — two-thirds of a month’s activity in 48 hours.
Source IPs: 8 unique addresses across Hong Kong, Japan, the Netherlands, Taiwan and the United States.
2026-08-18 — CISA adds CVE-2026-55040 to the KEV catalog, remediation due 2026-08-21.
Attribution: none. As SecurityWeek put it, “there does not appear to be any public information on who is behind the exploitation of these weaknesses.” Ransomware use is recorded in KEV as Unknown.

The absolute numbers are small, and it would be easy to read them as reassuring. They are not. They are early. The pattern — a quiet month, then a step change within 24 hours of a public PoC — is the pattern that precedes commodity scanning, and it is the same pattern SharePoint has followed four times already this year.

Post-Exploitation Impact

Full read access to site content as the impersonated user. If that user is a site collection administrator, that is every document in the site collection.
Write access. The PoC deliberately retrieves the form digest from /_api/contextinfo — the token SharePoint requires for state-changing operations. This is not a read-only bug.
Escalation to code execution. Chained with CVE-2026-63520, arbitrary code runs as the SharePoint service account.
Credential and secret harvesting. A SharePoint farm holds service account credentials, connection strings and secrets in the config database and in BCS connections. Code execution as the service account reaches them.
Active Directory reconnaissance from a trusted position. The exploit path already involves querying the domain controller; a foothold on the farm makes that enumeration authenticated and unremarkable.
Access to indexed content beyond SharePoint. The search crawler indexes connected file shares. The index is a map of where the organization’s sensitive data lives.
Persistence. SharePoint offers an abundance of durable footholds — web parts, event receivers, timer jobs, custom solutions, modified web.config files. None of them are removed by installing a patch.
A trusted position for internal phishing. Documents and links served from the corporate intranet carry implicit trust that no external domain can match.

⚠️ Impact Assessment

Immediate Impact

Unauthenticated impersonation of any user, including administrators, over the network with no user interaction.
No workaround for the vulnerability itself. The fix is the patch. Network restriction and a Layer 7 reverse proxy reduce who can reach the endpoint; they do not repair the validation pipeline.
A public, automated PoC exists — and it self-discovers the parameters it needs, including administrator accounts.
Two patches are required, not one. July closes the bypass; August closes the RCE. Farms patched only in July remain exposed to the second half of the chain.
The KEV deadline has already passed. CISA’s remediation date was 2026-08-21. If this is still open, you are behind a federal deadline that reflects a real assessment of risk.
Patching does not evict an attacker. If your farm was reachable and unpatched at any point since July 14 — and especially since August 11 — patching is step one of two. Step two is hunting.

Affected Versions

Product	Vulnerable versions	Fixed build	July 2026 KB (CVE-2026-55040)
SharePoint Server Subscription Edition	< 16.0.19725.20434	16.0.19725.20434	KB5002882
SharePoint Server 2019	< 16.0.10417.20175	16.0.10417.20175	KB5002883 (+ MUI KB5002885)
SharePoint Enterprise Server 2016	< 16.0.5561.1001	16.0.5561.1001	KB5002891 (+ MUI KB5002892)
SharePoint Online (Microsoft 365)	Not affected	—	—

And the second half of the chain — CVE-2026-63520, released a month later:

Product	Fixed build	August 2026 KB (CVE-2026-63520)
SharePoint Server Subscription Edition	16.0.19725.20522	KB5002893
SharePoint Server 2019	16.0.10417.20198	KB5002894 (+ MUI KB5002896)
SharePoint Enterprise Server 2016	16.0.5565.1001	KB5002905 (+ MUI KB5002906)

The support-lifecycle problem. Per Microsoft’s own lifecycle pages, SharePoint Server 2016 and SharePoint Server 2019 both reached the end of extended support on 2026-07-15, 06:59:59 PT — which means the July 14 update that fixed CVE-2026-55040 was the last Patch Tuesday inside their supported window. Microsoft nonetheless shipped an August 11 update for both (KB5002905/KB5002906 for 2016, KB5002894/KB5002896 for 2019, per Microsoft’s own SharePoint release-notes page), and that update carries the CVE-2026-63520 fix. Apply it. But do not build a plan on it repeating: there is no announced Extended Security Update programme for SharePoint Server 2016 or 2019, and the migration path Microsoft points at is SharePoint Server Subscription Edition. The next chain half may not come with a patch for you.

Affected Environments

Internet-published farms — extranets, partner portals, remote-access intranets. Close to 10,000 SharePoint servers are internet-facing, per Shadowserver. This is the acute case.
Internal-only farms on flat networks. AV:N means “network”, not “internet”. If any workstation can reach the farm over HTTPS, so can anything that lands on a workstation.
Farms using server-to-server authentication — hybrid SharePoint, Exchange integration, Workflow Manager. These are the deployments where the S2S code path is a live, exercised feature rather than dormant code.
Farms with Business Connectivity Services in use — directly relevant to the chain partner, and common in exactly the integration-heavy environments that cannot easily move to SharePoint Online.
Anyone still on SharePoint 2016 or 2019 — affected, out of extended support since July 15, 2026, and dependent on Microsoft’s continued goodwill for future fixes.
Farms with a quarterly patch cadence. The interval between “PoC published” and “honeypots attacked” was one day. A quarterly cadence is not a defence against that; it is a way of finding out later.

Attacker Profiles

Opportunistic mass scanners. The precondition for commodity exploitation — a public, parameter-discovering PoC — is already satisfied. This is the population the 8-IP telemetry represents, and it is the one that grows.
Ransomware operators. Corporate document repositories are ideal ransomware targets: high business impact, high regulatory exposure, and a credible extortion story. KEV records ransomware use as Unknown today. SharePoint’s own 2026 record — CVE-2026-45659 in the same KEV catalog is flagged as known ransomware-associated — suggests how that field tends to change.
State-sponsored actors. An intranet is a curated archive of an organization’s most sensitive material, and an authentication bypass produces access that looks exactly like a legitimate user. For long-dwell espionage, that is close to ideal.
Initial access brokers. Administrative access to a corporate SharePoint farm is premium, resellable inventory.
Insiders and contractors. No credentials means no audit trail tied to a real account. Anyone with network reach can act as anyone else.

🛡️ Mitigation Strategies

Immediate Actions (Priority 1) ⚡

Establish your exact farm build. Run this from the SharePoint Management Shell on a farm server (or load the snap-in into Windows PowerShell first). Get-SPFarm returns the local farm; BuildVersion is a read-only System.Version in major.minor.phase.build form.

# Load the SharePoint snap-in if you are not in the SharePoint Management Shell.
Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue

# The farm's current build number.
Get-SPFarm | Select-Object -ExpandProperty BuildVersion

Compare the result against the tables above. You need both thresholds:

Product	Patched for CVE-2026-55040 (July)	Patched for CVE-2026-63520 (August)
Subscription Edition	>= 16.0.19725.20434	>= 16.0.19725.20522
SharePoint 2019	>= 16.0.10417.20175	>= 16.0.10417.20198
SharePoint 2016	>= 16.0.5561.1001	>= 16.0.5565.1001

A build that clears the July threshold but not the August one means the bypass is fixed and the RCE half is not.

Check every server in the farm, not just one. A farm at build N can still contain a server that failed to complete the upgrade. Get-SPProduct reports the SharePoint products installed and the versions of all updates applied; -Local restricts it to the current server.
```
# Products and applied update versions on this server.
Get-SPProduct -Local

# Farm-wide view (omit -Local): lists all servers and their patch status.
Get-SPProduct
```
Do not use Get-HotFix for this. Get-HotFix queries Win32_QuickFixEngineering, which enumerates operating system updates. SharePoint public updates are Office-family patches and will not reliably appear there. A farm can be badly out of date while Get-HotFix looks entirely healthy. Use Get-SPProduct and the farm build version, or Central Administration’s Upgrade and Migration > Check product and patch installation status page.
Apply both updates if you have not. July’s KB closes CVE-2026-55040; August’s closes CVE-2026-63520. On SharePoint 2016 and 2019, the August update is available despite the July 15 end of extended support — take it now rather than assuming it will still be there later. Follow Microsoft’s normal sequence: install the language-independent package first, then the MUI/language package, then run the SharePoint Products Configuration Wizard (or PSConfig) on every server to complete the upgrade. An installed binary with an incomplete configuration upgrade is not a patched farm.
Reduce who can reach the farm. There is no configuration change that repairs the validation pipeline, so restrict reachability instead. CISA’s guidance for SharePoint Server is explicit: avoid exposing SharePoint Servers directly to the internet unless necessary, and where it is necessary, place the server behind a Layer 7 reverse proxy or equivalent application-layer control that requires authentication and can inspect and filter requests. Internally, the same logic applies — a farm reachable from every workstation VLAN is reachable from every compromised workstation.
Do not re-enable file-backed BDC model import without a reason. August’s update disables it by default specifically to shrink the CVE-2026-63520 surface. The Enable-BdcmFileImport cmdlet exists to switch it back on for a site collection where the business genuinely needs it. Confirm nobody has run it reflexively to “fix” a broken import.
Assume compromise if the farm was exposed. If an internet-reachable farm was unpatched on or after August 12, 2026 — the day PoC-driven exploitation began — treat a compromise assessment as mandatory, not optional. Proceed to detection below.

Detection Measures 🔍

The good news: weakness 3 logs itself. SharePoint writes a ULS entry every time it accepts an issuer it does not trust. That message is the highest-fidelity indicator available for this CVE, because a healthy farm has no legitimate reason to produce it.

Hunt the fail-open message in ULS. Get-SPLogEvent reads the ULS trace logs; -StartTime and -EndTime bound the search and are strongly recommended for performance.

Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue

# Search the ULS trace log for the fail-open decision from weakness 3.
# A hit means SharePoint accepted a token from an issuer it does not trust.
Get-SPLogEvent -StartTime (Get-Date).AddDays(-30) |
    Where-Object { $_.Message -like '*accepted Issuer because no registered STS matches*' } |
    Select-Object Timestamp, Area, Category, Message |
    Format-List

Two caveats before you treat an empty result as good news. First, ULS retention is finite — check what you actually keep, because 30 days of history may not exist:

# Farm ULS settings. LogLocation is the trace-log directory;
# DaysToKeepLogs is how long entries survive.
Get-SPDiagnosticConfig

Second, whether this message is written at all depends on the configured trace level for the relevant category. If ULS is turned down, absence of the message is not evidence of absence of the attack.

Grep the ULS files directly — faster than Get-SPLogEvent across a large history, and useful on archived logs. Substitute the LogLocation value from the command above:

# Default ULS location for the 16 hive; adjust to your LogLocation.
$uls = 'C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\LOGS'

Select-String -Path (Join-Path $uls '*.log') `
    -Pattern 'accepted Issuer because no registered STS matches' |
    Select-Object Filename, LineNumber, Line

Correlate the two-request pattern in IIS logs. The exploit reads the metadata endpoint, then hits an authenticated API. A single client IP doing both is a strong signal.
```
# IIS default log root; W3SVC<siteid> per site.
$iis = 'C:\inetpub\logs\LogFiles'

Select-String -Path (Join-Path $iis 'W3SVC*\*.log') `
    -Pattern '/_layouts/15/metadata/json/1|/_api/contextinfo|/_vti_bin/sites\.asmx|/_api/web/currentuser' |
    Select-Object -ExpandProperty Line
```
Important limitation: IIS logs do not record request headers by default, so the Authorization: Bearer token is not in them. You cannot search IIS logs for alg: none. What you can do is spot the access pattern — metadata endpoint followed by authenticated API calls from the same client — and note that cs-username will often be blank or unexpected for these requests, because the caller never performed a normal sign-in.

A Sentinel / Log Analytics query for the same pattern. This flags any client IP that touched two or more of the relevant endpoints. Column names are per the W3CIISLog schema.

W3CIISLog
| where TimeGenerated > ago(30d)
| where csUriStem has_any (
    "/_layouts/15/metadata/json/1",
    "/_api/contextinfo",
    "/_api/web/currentuser",
    "/_vti_bin/sites.asmx")
| summarize
    Endpoints  = make_set(csUriStem),
    Requests   = count(),
    Statuses   = make_set(scStatus),
    Users      = make_set(csUserName),
    FirstSeen  = min(TimeGenerated),
    LastSeen   = max(TimeGenerated)
    by cIP, Computer
| where array_length(Endpoints) >= 2
| order by LastSeen desc

Tune before deploying: legitimate S2S peers and monitoring agents will hit some of these endpoints routinely. Baseline your known-good source addresses and exclude them, rather than dropping the endpoints from the query.

Look for what an attacker would do next, not just the entry. The bypass is quiet; the follow-on activity is not. Review, over the same window:
- New or modified farm solutions, web parts, event receivers and timer jobs — the standard SharePoint persistence mechanisms.
- Changes to web.config on any web front end.
- Site collection administrator additions, and permission grants that no change ticket explains.
- w3wp.exe spawning child processes — particularly cmd.exe, powershell.exe, csc.exe or net.exe. On a healthy SharePoint front end this is close to nil, which makes it an unusually clean detection for the CVE-2026-63520 half of the chain.
- Unexpected outbound connections from web front ends.
- Anomalous bulk document access or search queries from a single identity.
Check your KEV posture generally. CVE-2026-55040’s remediation deadline was 2026-08-21. If it slipped, the same process is very likely carrying the other four exploited SharePoint CVEs of 2026 as well. Query your scanner for the whole set: CVE-2026-32201, CVE-2026-45659, CVE-2026-50522, CVE-2026-55040, CVE-2026-56164, CVE-2026-58644, CVE-2026-63520.

Long-term Security Improvements

Get SharePoint off the public internet. If external users need documents, put an authenticating reverse proxy or a VPN in front of the farm — exactly as CISA recommends. An attacker who cannot complete a TLS handshake with your farm cannot exploit a token-validation bug in it, no matter how elegant.
Migrate off SharePoint 2016 and 2019. Both left extended support on July 15, 2026. There is no announced ESU programme. The August 2026 update for these versions was a fortunate outcome, not an entitlement, and building a security plan around Microsoft’s continued generosity is not a plan.
Patch the management-adjacent estate on the fastest cadence you have. The interval between public PoC and observed exploitation for this CVE was one day. Any patch cycle measured in months is, functionally, a decision not to defend against this class of event.
Track the chain, not the CVE. This vulnerability’s real severity only appears when you notice that its partner shipped a month later. Build the habit of asking, for every vendor advisory: is this a complete bug, or half of one? Vendor write-ups from researchers — Rapid7’s here — routinely state this outright, while the vendor’s own advisory does not.
Stop treating a patch date as an all-clear. For a vulnerability with a public PoC, the interesting question is not “have we patched?” but “were we reachable and unpatched while it was being exploited?” Those need different responses, and only one of them is an update.
Turn ULS logging into something you actually read. SharePoint told the truth in its own logs — accepted Issuer because no registered STS matches is a fail-open confession. It is worth nothing if the logs are local-only, short-retained, and unread. Forward ULS to your SIEM, retain it for a period matched to your detection ambitions, and alert on high-fidelity strings like this one.
Inventory your S2S trust relationships. Know which servers are registered via New-SPTrustedSecurityTokenIssuer and why. Trust configured years ago for a decommissioned integration is pure attack surface, and it also makes detection harder by adding legitimate noise to the code path.
Reduce SharePoint service account privilege. Code execution as the service account is the end state of the chain. How much that is worth to an attacker is a configuration decision you already made, and can revisit.
Include the intranet in incident response planning. Ask the uncomfortable question before you need the answer: if the SharePoint farm is untrusted, what did the attacker read? Most organizations cannot answer that, because SharePoint access logging was never provisioned for forensic use.

🎯 Why is this Critical?

Four independent failures in one validation pipeline. This is not a subtle logic slip. Signature checking is disabled outright, the key comes from attacker input, an unknown issuer is accepted, and the signature check is a string-length test. Any one of these being correct would have stopped the attack.
Zero prerequisites. No credentials, no user interaction, low complexity, one HTTP request. The only friction is knowing a username — and the public PoC brute-forces that for you.
The server hands over the key material. SharePoint publishes its STS signing certificate at an unauthenticated endpoint. That is fine when signatures are verified. It is the first step of an exploit when they are not.
It is exploited, and it is in KEV. Added 2026-08-18, remediation due 2026-08-21. That deadline has passed.
Exploitation followed the PoC by one day. 12 recorded attempts in a month; 8 of them in the 48 hours after publication. The gating factor was never difficulty — it was information.
Patching in July was not enough. The RCE half of the chain shipped on August 11. A farm that took the July update and stopped is exposed to exactly the vulnerability that makes the bypass matter.
The target set is high-value by construction. On-premises SharePoint in 2026 holds the material that was too sensitive or too integrated to move to the cloud. Close to 10,000 of these servers are internet-facing.
Two of the three affected versions are out of support. SharePoint 2016 and 2019 left extended support on July 15, 2026, with no ESU programme. They got an August patch anyway. There is no guarantee for the next one.
This is SharePoint’s fifth exploited flaw of 2026. CVE-2026-32201, CVE-2026-45659, CVE-2026-50522, CVE-2026-56164, CVE-2026-58644 — and now this. At some point a pattern stops being a run of bad luck and becomes a reason to reconsider whether the product belongs on your perimeter.

🚀 Timeline and Disclosure

2026-05-18 — Rapid7 discloses the full exploit chain to Microsoft. The work is a Pwn2Own Berlin 2026 entry by Stephen Fewer, combining the authentication bypass with a SharePoint RCE.
2026-07-14 — Microsoft patches CVE-2026-55040 in the July Patch Tuesday release: KB5002882 (Subscription Edition, 16.0.19725.20434), KB5002883/KB5002885 (2019, 16.0.10417.20175), KB5002891/KB5002892 (2016, 16.0.5561.1001). The NVD record is published the same day with CVSS 3.1 9.1 and CWE-1390. Advisory language stays generic; no technical detail is public.
2026-07-15, 06:59:59 PT — SharePoint Server 2016 and SharePoint Server 2019 reach the end of extended support. The July 14 update was the last one inside their supported window.
2026-07-19 — First exploitation attempt recorded by KEVIntel — five days after the patch, three weeks before any public technical detail.
2026-08-11 — Rapid7 publishes the technical analysis and a working proof-of-concept (github.com/sfewer-r7/CVE-2026-55040), documenting all four weaknesses. On the same day, Microsoft patches CVE-2026-63520, the RCE half of the chain: KB5002893 (SE, 16.0.19725.20522), KB5002894/KB5002896 (2019, 16.0.10417.20198), KB5002905/KB5002906 (2016, 16.0.5565.1001). The August update also disables file-backed BDC model import by default.
2026-08-12 — Defused reports honeypot exploitation, explicitly using Rapid7’s PoC. Rapid7 ships authenticated detection checks in InsightVM, Nexpose and Exposure Command.
2026-08-12 to 08-13 — 8 of the 12 total recorded attempts occur, from 8 IPs across Hong Kong, Japan, the Netherlands, Taiwan and the United States.
2026-08-18 — CISA adds CVE-2026-55040 to the KEV catalog (CWE-1390), with a remediation deadline of 2026-08-21 under BOD 26-04. Ransomware use: Unknown.
2026-08-19 — The NVD record is last modified.
2026-08-21 — KEV remediation deadline passes. CVE-2026-55040 is confirmed present in KEV catalog version 2026.08.21 (1,674 entries).

🔗 Resources and References

CVE: CVE-2026-55040
NVD: NVD — CVE-2026-55040
Vendor advisory: MSRC Security Update Guide — CVE-2026-55040
CWE: CWE-1390: Weak Authentication
CISA KEV Catalog: Known Exploited Vulnerabilities — listed since 2026-08-18, due 2026-08-21
Technical analysis: Microsoft SharePoint JWT Token Authentication Bypass Technical Analysis — Rapid7
Chain partner: CVE-2026-63520 — SharePoint Remote Code Execution (Rapid7)
Patch reference: SharePoint updates — Microsoft Learn (build numbers and KBs for every version)
Support lifecycle: SharePoint Server 2016 and SharePoint Server 2019 — extended support ended 2026-07-15
Related SharePoint CVEs exploited in 2026: CVE-2026-32201, CVE-2026-45659 (KEV, ransomware-associated), CVE-2026-50522, CVE-2026-56164, CVE-2026-58644
Our earlier coverage: InSEKurity of the Week CW27/2026 — SharePoint Deserialization RCE (CVE-2026-45659)

💼 SEKurity Supports You

The instructive thing about CVE-2026-55040 is not that SharePoint had an authentication bug. It is where the bug was. Nobody forgot to authenticate. There is an entire validation pipeline here — a token handler, an issuer resolver, a signature check, a dedicated ValidateIssuer() method — and every stage of it ran. Each stage simply trusted that a different stage had done the cryptography. The outer token was exempt because the actor token would prove authenticity; the actor token was never verified because resolving its key was mistaken for validating against it. Four correct-looking functions, one complete failure. This is what security defects look like in mature products: not missing controls, but controls that each assume someone else is holding the line.

That is exactly the class of flaw an automated scanner cannot find and a checklist cannot catch. A scanner sees an authentication mechanism and records that one exists. Testing whether it can be convinced — whether a token the server should reject is accepted, whether an endpoint that publishes certificate metadata becomes a problem when signature verification is weak, whether a foothold as a low-privilege user converts into code execution on the front end — takes somebody following the trust relationships end to end and trying to break each assumption in turn. The second lesson is about the exploitation curve. Nothing about this vulnerability changed on August 11. The patch had been available for four weeks. What changed was that the technical detail became public, and exploitation followed within a day. Any patch cadence slower than that is a bet that nobody will write up the bugs in your stack. We help clients on both fronts — testing whether the authentication and authorization boundaries around collaboration platforms actually hold under pressure rather than merely existing, mapping which internal systems are genuinely reachable from where, converting theoretical footholds into demonstrated impact so that prioritization arguments stop being hypothetical, and validating that the detections you are counting on — like a ULS line that literally reads “accepted Issuer because no registered STS matches” — would reach an analyst rather than a log file nobody has opened.

Our Services

Penetration Testing: Web applications, mobile apps (Android & iOS), SAP systems, Active Directory
Large-Scale Attacks: Perimeter testing, IT infrastructure testing, Red Team engagements
Security Awareness: Phishing campaigns, hacking demonstrations

Act now — before attackers do.

Contact:

🌐 Website: www.sekurity.de

📧 Inquiries: www.sekurity.de/kontakt

📱 LinkedIn: SEKurity GmbH

Your SEKurity Team — Your Trusted Adversaries

The security of your collaboration and intranet infrastructure is our drive.

InSEKurity of the Week (CW34/2026): Microsoft SharePoint JWT Authentication Bypass (CVE-2026-55040)