CVE-2026-50522: Unauthenticated Deserialization RCE in Microsoft SharePoint Server – Advisory + Nuclei Detection

In its July 2026 Patch Tuesday, Microsoft shipped an emergency-grade fix for CVE-2026-50522, a critical, unauthenticated remote code execution vulnerability in on-premises Microsoft SharePoint Server. Within days the reason to act became undeniable: a working proof-of-concept went public, attackers began exploiting it in the wild, and CISA added it to the Known Exploited Vulnerabilities catalog with a federal patch deadline. Two facts make this one a drop-everything item: it needs no authentication, and the payoff is not just code execution – attackers are pulling ASP.NET machine keys in a single request, which lets them forge authentication tokens that survive patching.

This advisory is three things at once. First, a plain-English explanation of what CVE-2026-50522 is, who is affected, and why patching alone is not enough. Second, a ready-to-run Nuclei detection template you can copy, paste, and scan with today – the same non-destructive template shipped in Sn1per‘s curated set. Third, a walkthrough of how to find every exposed SharePoint server across an attack surface and flag the ones still on a vulnerable build. Credit where it is due: CVE-2026-50522 was reported to Microsoft by DEVCORE researcher “splitline” and demonstrated live at Pwn2Own Berlin (ZDI-26-412); the public proof-of-concept and in-the-wild activity followed the July disclosure.

CVE-2026-50522 at a glance

• CVE: CVE-2026-50522 – insecure deserialization of untrusted data (CWE-502) in Microsoft SharePoint Server.
• Impact: unauthenticated, pre-auth remote code execution as the SharePoint service account, followed by machine-key theft for persistence.
• CVSS: 9.8 Critical (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). Microsoft tagged it “Exploitation More Likely.”
• Affected: all supported on-premises editions – Enterprise Server 2016, Server 2019, and Subscription Edition. SharePoint Online (Microsoft 365) is not affected.
• Fixed: the July 2026 security updates – build 16.0.5561.1001 (2016), 16.0.10417.20175 (2019), 16.0.19725.20434 (Subscription Edition) or later.
• Status: public PoC, active in-the-wild exploitation, and CISA KEV as of July 22, 2026 (FCEB remediation due July 25).
• Fix now: patch to a fixed build, then rotate ASP.NET machine keys – a patch alone does not evict an attacker who already has your keys.

What is CVE-2026-50522?

CVE-2026-50522 is an insecure-deserialization flaw (CWE-502) in the way SharePoint Server processes authentication tokens. Under the hood, SharePoint uses Windows Identity Foundation – the .NET framework for reading and writing security tokens – and its SessionSecurityTokenHandler reconstructs a SessionSecurityToken from data supplied in a sign-in request. The vulnerable code path deserializes that attacker-controlled data with the legacy BinaryFormatter before any application-level validation runs.

BinaryFormatter is the crux of the risk. It has been recognized for years as a dangerous serializer because reconstructing an object graph can invoke methods on attacker-chosen types before your code ever inspects the result. Microsoft has discouraged its use for exactly this reason, and a long line of critical enterprise RCEs has come from feeding it untrusted bytes. Here, the untrusted bytes arrive as a forged security token, and the object graph is a gadget chain that ends in command execution.

The delivery vehicle is WS-Federation. SharePoint exposes a trust sign-in endpoint at /_trust/default.aspx that accepts a wsignin1.0 sign-in response. An unauthenticated attacker crafts a RequestSecurityTokenResponse that wraps a malicious SecurityContextToken; the serialized .NET gadget rides inside the token as a <Cookie> value. When SharePoint deserializes that token, the gadget fires and executes code inside the IIS worker process (w3wp.exe) under the SharePoint service account. No login, no user interaction, no phishing – a single crafted POST.

One point worth flagging honestly for triage: Microsoft’s own advisory contradicts itself on whether authentication is required. The MSRC advisory prose says an attacker “authenticated as at least a Site Owner” could execute code, yet Microsoft’s own published CVSS vector for the same CVE is PR:N (no privileges required), and NVD reproduces that vector. The independent evidence sides with unauthenticated: the flaw was reported through Pwn2Own / ZDI (ZDI-26-412) as an unauthenticated bug, and captured in-the-wild requests carry no authentication material (the Site-Owner language may in fact belong to the paired CVE-2026-58644). When the vendor disagrees with itself, defend for the worse case – treat it as reachable pre-authentication and prioritize accordingly – while confirming the exact privilege requirement against Microsoft’s advisory for your environment.

What turns a serious RCE into an emergency is the post-exploitation goal. Rather than stopping at a shell, attackers use CVE-2026-50522 to read the server’s ASP.NET machine keys – the cryptographic material SharePoint uses to sign and protect authentication data – in as little as one request. With those keys, an attacker can forge valid authentication tokens at will, impersonate users, and walk back in after the box is patched. This is the same playbook seen in the 2025 SharePoint “ToolShell” wave, and it is why every credible advisory says the same thing: patch, then rotate machine keys.

Affected and fixed versions

CVE-2026-50522 affects every supported on-premises SharePoint Server edition. The cloud-hosted SharePoint Online is a separate, continuously updated codebase and is not in scope. The practical breakdown, by product line and build number, is below. SharePoint advertises a build in the MicrosoftSharePointTeamServices response header as 16.0.0.<build>, so the fourth number is the one to compare.

SharePoint edition	Affected builds	Fixed build (July 2026)
Enterprise Server 2016	Below 16.0.5561.1001	16.0.5561.1001
Server 2019	Below 16.0.10417.20175	16.0.10417.20175
Subscription Edition	Below 16.0.19725.20434	16.0.19725.20434
SharePoint Online (M365)	Not affected	N/A

The takeaway: if a farm’s running build is below the fixed build for its line, treat it as vulnerable and patch immediately. One caveat that trips people up during audits – a security update approved in WSUS or Configuration Manager is not the same as installed. The only build that counts is the one actually running on each server in the farm, which you can read with (Get-SPFarm).BuildVersion in the SharePoint Management Shell.

How the exploit chain works

The attack is a single unauthenticated HTTP POST to the WS-Federation trust endpoint. The request looks ordinary – it is a standard wsignin1.0 sign-in response – but the token it carries is malicious. In skeleton form, and with the weaponized payload deliberately redacted, the request is shaped like this:

POST /_trust/default.aspx HTTP/1.1
Host: sharepoint.example.com
Content-Type: application/x-www-form-urlencoded

wa=wsignin1.0&wctx=https://sharepoint.example.com/&wresult=
  <RequestSecurityTokenResponse ...>
    <RequestedSecurityToken>
      <SecurityContextToken ...>
        <Cookie ...>[BASE64 SERIALIZED .NET GADGET - REDACTED]</Cookie>
      </SecurityContextToken>
    </RequestedSecurityToken>
  </RequestSecurityTokenResponse>

Inside that redacted blob is a serialized .NET BinaryFormatter payload. Public proof-of-concept code assembles it with a standard tool such as ysoserial.net (a common gadget chain here is TypeConfuseDelegate), DEFLATE-compresses the raw bytes, and Base64-encodes them to fit the cookie field, then wraps the result in the SecurityContextToken shown above. When SharePoint’s SessionSecurityTokenHandler deserializes the cookie, the gadget chain executes the attacker’s command in w3wp.exe. Public PoCs confirm the primitive by having the injected command call out to an attacker-controlled out-of-band server, so a callback is proof of code execution.

We are deliberately not publishing a working exploit here. What follows is detection only – version fingerprinting that tells you whether a given SharePoint server sits below a fixed build, so you can prioritize patching. That is the responsible half, and for defenders it is the useful half. It is the same approach we took in our earlier advisories, such as wp2shell (CVE-2026-63030) and CVE-2024-21733 (Apache Tomcat request smuggling): explain the flaw, then ship a safe detection you can run at scale.

Am I affected? Quick manual checks

On a host you control, the authoritative check is the SharePoint Management Shell, run on a farm server:

# Authoritative: ask the farm directly
(Get-SPFarm).BuildVersion
# At-risk if the build is below your line's fix:
#   2016 < 16.0.5561.1001 | 2019 < 16.0.10417.20175 | SE < 16.0.19725.20434

From the outside, SharePoint advertises a build in a response header. Any authenticated or anonymous page that returns the header is enough to fingerprint the line:

# The build appears in the MicrosoftSharePointTeamServices header as 16.0.0.<build>
curl -sk -D - https://sharepoint.example.com/ -o /dev/null | grep -i MicrosoftSharePointTeamServices

# Some farms also expose it via the FrontPage service file:
curl -sk https://sharepoint.example.com/_vti_pvt/service.cnf | grep -i vti_extenderversion

One caveat that matters for accuracy: the MicrosoftSharePointTeamServices header reports a minimum build level and can lag the farm’s true patch state, because of how the value is written back during administrative operations. Treat an in-range header as “confirm this,” not a final verdict, and verify with (Get-SPFarm).BuildVersion on the host. It never over-reports the risk in a way that would make you skip patching, which is the safe direction for a triage signal.

Nuclei detection template for CVE-2026-50522

To check one server or ten thousand, a version-based Nuclei template is the fastest path. The template below – the same one shipped in Sn1per’s curated template set – passively fingerprints the SharePoint build from the MicrosoftSharePointTeamServices response header and flags any farm whose build falls below the July 2026 fix for its product line, using Nuclei’s compare_versions DSL. It sends no deserialization payload and never touches /_trust/default.aspx; it only reads a version header, so it is safe to run against production.

id: CVE-2026-50522

info:
  name: Microsoft SharePoint Server - Unauthenticated Deserialization RCE (CVE-2026-50522)
  author: xer0dayz
  severity: critical
  description: |
    Microsoft SharePoint Server (on-premises) is affected by CVE-2026-50522, a
    pre-authentication remote code execution vulnerability caused by insecure
    BinaryFormatter deserialization of untrusted data (CWE-502) in the Windows
    Identity Foundation SessionSecurityTokenHandler. An unauthenticated attacker
    POSTs a forged WS-Federation sign-in response (wa=wsignin1.0) to
    /_trust/default.aspx whose SecurityContextToken cookie carries a serialized
    .NET gadget chain; SharePoint deserializes it and executes code in the IIS
    worker process (w3wp.exe) under the SharePoint service account. This template
    is NON-DESTRUCTIVE: it detects on-premises SharePoint from the
    MicrosoftSharePointTeamServices response header, extracts the advertised build,
    and flags builds below the July 2026 fixed levels per product line (Enterprise
    Server 2016 < 16.0.5561.1001, Server 2019 < 16.0.10417.20175, Subscription
    Edition < 16.0.19725.20434). It sends no deserialization payload.
  remediation: |
    Install the July 2026 SharePoint security updates so the running farm build
    meets or exceeds 16.0.5561.1001 (2016), 16.0.10417.20175 (2019), or
    16.0.19725.20434 (Subscription Edition). A build approved in WSUS is NOT
    installed - verify with (Get-SPFarm).BuildVersion. Because attackers steal
    ASP.NET machine keys for persistence, ROTATE machine keys after patching.
  reference:
    - https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-50522
    - https://nvd.nist.gov/vuln/detail/CVE-2026-50522
    - https://www.cisa.gov/known-exploited-vulnerabilities-catalog
  classification:
    cvss-metrics: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
    cvss-score: 9.8
    cve-id: CVE-2026-50522
    cwe-id: CWE-502
  metadata:
    verified: true
    max-request: 2
    vendor: microsoft
    product: sharepoint_server
    shodan-query: http.component:"Microsoft SharePoint"
  tags: cve,cve2026,sharepoint,microsoft,rce,deserialization,unauth,kev,pwn2own

http:
  - method: GET
    path:
      - "{{BaseURL}}/"
      - "{{BaseURL}}/_layouts/15/start.aspx"

    stop-at-first-match: true
    redirects: true
    max-redirects: 2

    matchers-condition: or
    matchers:
      - type: dsl
        name: sharepoint-2016-below-16.0.5561.1001
        dsl:
          - "compare_versions(version, '>= 16.0.0.4000', '< 16.0.0.5561')"

      - type: dsl
        name: sharepoint-2019-below-16.0.10417.20175
        dsl:
          - "compare_versions(version, '>= 16.0.0.10000', '< 16.0.0.10417')"

      - type: dsl
        name: sharepoint-subscription-edition-below-16.0.19725.20434
        dsl:
          - "compare_versions(version, '>= 16.0.0.14000', '< 16.0.0.19725')"

    extractors:
      - type: kval
        name: version
        internal: true
        kval:
          - MicrosoftSharePointTeamServices

      - type: kval
        name: sharepoint_build
        kval:
          - MicrosoftSharePointTeamServices

Save it as CVE-2026-50522.yaml and run it against a single target or a list of hosts:

# Single target
nuclei -t CVE-2026-50522.yaml -u https://sharepoint.example.com/

# A whole list of SharePoint hosts
nuclei -t CVE-2026-50522.yaml -l sharepoint-hosts.txt

# Example match against an affected Server 2019 farm (build 16.0.0.10337):
[CVE-2026-50522] [http] [critical] https://sharepoint.example.com/ [sharepoint-2019-below-16.0.10417.20175] [16.0.0.10337]

The named matcher tells you which product line and fix level matched (for example sharepoint-2019-below-16.0.10417.20175), and the extracted build appears in the results, so triage is immediate. Because the check is version-based, it has two blind spots. First, confirm an in-range hit with (Get-SPFarm).BuildVersion, since the header advertises a minimum build. Second, treat a no-match as inconclusive, not clean: if a reverse proxy, WAF, or hardened configuration strips the version header, the template has nothing to compare and stays silent, which means “unknown, verify manually,” not “patched.” For anyone who needs defensible coverage across an entire estate – including SharePoint servers nobody remembered they exposed – the next step up is Sn1per.

Detecting CVE-2026-50522 across your attack surface with Sn1per

One template against one URL is fine for a spot check. The real problem is scale and discovery: most organizations do not have a clean list of every SharePoint server they expose. An extranet collaboration site, a forgotten project farm, a subsidiary’s on-prem SharePoint on an acquired domain – those are exactly the hosts that miss the patch cycle and quietly sit on a vulnerable build for weeks. Finding them is an attack-surface problem before it is a scanning problem.

Sn1per is built for that. It runs discovery and detection as one engine: it enumerates the surface (subdomains, live hosts, services, technologies), fingerprints what is running, and runs its curated Nuclei set – including this CVE-2026-50522 template – against everything it finds, into a persistent named workspace. Instead of “scan this one URL,” the workflow becomes “discover every SharePoint we expose and flag the ones on a vulnerable build.”

# Discover the surface, then run web detections (incl. the CVE-2026-50522 template)
# into a persistent workspace
sniper -t example.com -m recon -w acme-sp
sniper -t example.com -m web   -w acme-sp

# Pull the affected-version findings back out via the JSON API (Sn1per Professional 2026)
curl -sk -H "X-API-Key: $SN1PER_API_KEY" 
  "https://sn1per.local/pro/api.php?action=vulnerabilities&workspace=acme-sp" | jq '.'

Because Sn1per keeps results in workspaces, the same command from cron or a CI/CD pipeline re-checks the surface on a schedule, so a newly discovered or freshly stood-up SharePoint farm gets fingerprinted within a run rather than at the next annual pentest – the model we cover in continuous attack surface testing and automated penetration testing. Findings also feed Sn1per’s correlation layer, so a CVE-2026-50522 hit on a host that also exposes other weaknesses is ranked in context rather than as an isolated line item.

And because Sn1per is self-hosted – it has run on-prem since 2015 and is Docker-first – the entire scan, including the target list of your unpatched SharePoint servers, never leaves your perimeter. For an offensive-security tool inventorying your own exposure, that on-prem posture is the point: a map of what you have not patched yet is precisely the data you do not want sitting in someone else’s cloud.

Which Sn1per edition fits

Capability	Community Edition	Professional 2026	Enterprise
Curated Nuclei set incl. CVE-2026-50522 template	Yes	Yes	Yes
Discovery + detection engine	Yes	Yes	Yes
Scale	Single operator	Up to 150 assets, single operator	Near-unlimited, multi-operator
Web UI + scheduled scans	No	Yes	Yes
JSON API + SIEM / ticketing export	No	Yes	Yes
Multi-workspace / multi-team	No	No	Yes
Self-hosted / on-prem	Yes	Yes	Yes

Sn1per Community Edition is free and open-source and ships the same detection engine, so a spot check across a handful of hosts costs nothing. Sn1per Professional 2026 adds the web UI, scheduled scans, and the JSON API for teams that want continuous coverage and findings routed into a SIEM or ticket queue; live pricing is on the shop. Sn1per Enterprise scales to near-unlimited assets with multi-operator, multi-workspace management for MSSPs and large security teams (custom quote). If you are weighing the two paid tiers, our Professional vs Enterprise comparison breaks it down.

Remediation and mitigation

1. Patch. This is the only real fix. Install the July 2026 SharePoint security update so each server’s running build meets or exceeds 16.0.5561.1001 (2016), 16.0.10417.20175 (2019), or 16.0.19725.20434 (Subscription Edition). Verify the installed build on every farm server with (Get-SPFarm).BuildVersion rather than assuming a WSUS approval landed.

2. Rotate ASP.NET machine keys. Patching alone is not enough. Because attackers pull machine keys in a single request and use them to forge tokens that outlive the patch, any farm that was internet-exposed during the window should have its machine keys rotated after patching. The order matters, and so does the cmdlet: Set-SPMachineKey is what generates a new key, while Update-SPMachineKey only deploys the key already in the config database – so running Update alone just re-propagates the key an attacker may already have. Generate, deploy, then reset IIS on every server so the worker processes load the new key:

# After patching: GENERATE a new machine key, deploy it farm-wide, then reset IIS.
# Set-SPMachineKey with no key arguments mints a random key; without -Local it
# deploys to the whole farm. Update-SPMachineKey alone only re-deploys the existing key.
Set-SPMachineKey    -WebApplication https://sharepoint.example.com
Update-SPMachineKey -WebApplication https://sharepoint.example.com

# On SharePoint Subscription Edition / newer builds you can instead use:
#   Central Administration > Monitoring > Review job definitions
#   > "Machine Key Rotation Job" > Run Now

# Machine keys live in the IIS worker process (w3wp.exe), not the timer service,
# so finish with iisreset on EVERY SharePoint server in the farm:
iisreset

3. Reduce exposure and harden. Enable AMSI integration on SharePoint 2016 and 2019 so the platform can intercept malicious payloads, put the farm behind a reverse proxy or WAF that inspects the /_trust/ path for serialized .NET payload patterns, and restrict external access to authentication endpoints that do not need to be internet-facing. These reduce risk but are not substitutes for patching and key rotation.

4. Hunt for prior compromise. Because exploitation predates many patch windows, assume nothing. Inspect IIS logs for POST requests to /_trust/default.aspx carrying WS-Federation sign-in responses from unexpected external sources, and watch for unusual child processes spawned by w3wp.exe on SharePoint hosts – deserialization RCE commonly launches command interpreters or scripting hosts from the IIS worker process. Treat any evidence of access as a machine-key compromise and rotate.

Frequently asked questions

What is CVE-2026-50522? CVE-2026-50522 is a critical, unauthenticated remote code execution vulnerability in on-premises Microsoft SharePoint Server. It stems from insecure BinaryFormatter deserialization of untrusted data (CWE-502) in the Windows Identity Foundation token handler. An anonymous attacker POSTs a forged WS-Federation sign-in response to /_trust/default.aspx; SharePoint deserializes a malicious security token and executes attacker code as the SharePoint service account.

Which SharePoint versions are affected by CVE-2026-50522? All supported on-premises editions: Enterprise Server 2016 (below build 16.0.5561.1001), Server 2019 (below 16.0.10417.20175), and Subscription Edition (below 16.0.19725.20434). SharePoint Online in Microsoft 365 is not affected. Install the July 2026 security update to reach a fixed build.

Is CVE-2026-50522 being exploited in the wild? Yes. A public proof-of-concept was released in July 2026 and active in-the-wild exploitation followed within days. CISA added CVE-2026-50522 to its Known Exploited Vulnerabilities catalog on July 22, 2026, with a federal remediation deadline of July 25. Attackers are using it to steal ASP.NET machine keys for persistence.

Why do I need to rotate machine keys after patching CVE-2026-50522? Because the vulnerability lets an attacker read the server’s ASP.NET machine keys, which sign and protect authentication tokens. An attacker who captured those keys before you patched can forge valid tokens and regain access even after the update is installed. Patching closes the door; rotating machine keys changes the locks.

Is the CVE-2026-50522 Nuclei template safe to run in production? Yes. The template only reads the public MicrosoftSharePointTeamServices response header and compares the advertised build against the fixed builds. It sends no deserialization payload and never touches /_trust/default.aspx, so it is safe to run against production targets. Confirm any in-range hit against the farm’s actual build with (Get-SPFarm).BuildVersion.

CVE-2026-50522 is the kind of vulnerability that punishes incomplete inventory and slow key rotation more than slow patching alone: the servers that stay compromised are the ones nobody remembered they had, and the ones that got patched but never had their keys rotated. Patch what you know about today, rotate keys where exposure is possible, then use the template above – or Sn1per across your whole surface – to find the SharePoint you forgot.