core-jmp core-jmpdeath of core jump

CVE-2026-50522: Unauthenticated Deserialization RCE in Microsoft SharePoint Server — Advisory and Nuclei Detection

CVE-2026-50522 is a critical (CVSS 9.8) unauthenticated, pre-auth deserialization RCE in on-premises Microsoft SharePoint Server. A single crafted WS-Federation POST to /_trust/default.aspx carries a serialized .NET gadget that SharePoint deserializes with BinaryFormatter and runs as the service account — and attackers steal ASP.NET machine keys to survive patching. This advisory covers the affected/fixed builds, a non-destructive Nuclei detection template, attack-surface detection with Sn1per, and the patch-plus-key-rotation remediation.

oxfemale July 31, 2026 13 min read 41 reads
Export PDF
CVE-2026-50522: Unauthenticated Deserialization RCE in Microsoft SharePoint Server — Advisory and Nuclei Detection
Original text: “CVE-2026-50522: Unauthenticated Deserialization RCE in Microsoft SharePoint Server – Advisory + Nuclei Detection”xer0dayz (Founder of XeroSecurity), Sn1perSecurity (July 28, 2026). Code, tables and figures below are reproduced verbatim with attribution captions.

Executive Summary

CVE-2026-50522 is a critical, unauthenticated remote code execution vulnerability in on-premises Microsoft SharePoint Server. It is an insecure-deserialization flaw (CWE-502): the Windows Identity Foundation token handler deserializes attacker-controlled data with the legacy BinaryFormatter before any application-level validation, so a single crafted WS-Federation sign-in POST to /_trust/default.aspx can smuggle a serialized .NET gadget chain that executes in the IIS worker process (w3wp.exe) as the SharePoint service account. No login, user interaction, or phishing is required. Microsoft rates it CVSS 9.8 and CISA added it to the Known Exploited Vulnerabilities catalog, with public proof-of-concept code and in-the-wild exploitation already observed.

The nastier detail is persistence: in the same request an attacker can read the server’s ASP.NET machine keys, which sign and protect authentication tokens. With those keys, they can forge valid tokens that keep working after the patch is installed — so patching alone does not evict them. The correct response is patch and rotate machine keys. This advisory lays out the affected and fixed builds, how the exploit chain works, quick manual checks, a non-destructive Nuclei template for scanning your estate, how to fold that detection into attack-surface discovery with Sn1per, and the full remediation (including the exact key-rotation cmdlets).

Advisory cover: CVE-2026-50522 unauthenticated deserialization RCE in Microsoft SharePoint Server, with a Nuclei detection template and Sn1per attack-surface detection
CVE-2026-50522: unauthenticated deserialization RCE in Microsoft SharePoint Server. Source: original article.

CVE-2026-50522 at a glance

  • CVE: CVE-2026-50522 — insecure deserialization of untrusted data (CWE-502).
  • Impact: unauthenticated, pre-auth RCE 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); tagged “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: 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, on the CISA KEV list as of July 22, 2026 (FCEB remediation due July 25).
  • Critical post-fix action: patch to the fixed build, then rotate ASP.NET machine keys — patching alone does not evict an attacker who already holds your keys.

What is CVE-2026-50522?

The flaw lives in how SharePoint Server processes authentication tokens through Windows Identity Foundation. The vulnerable path hands attacker-controlled data to the legacy BinaryFormatter deserializer before application-level checks run, which is the classic recipe for a gadget-chain vulnerability. The delivery vehicle is WS-Federation via the /_trust/default.aspx endpoint: the attacker crafts a RequestSecurityTokenResponse that wraps a malicious SecurityContextToken, and the serialized .NET gadget rides inside that token as a <Cookie> value.

When SharePoint deserializes the token, the gadget fires and runs code in w3wp.exe under the SharePoint service account — no authentication, no user interaction, just one crafted POST. Because the same access lets an attacker extract the ASP.NET machine keys in a single request, they can forge tokens that survive patching. One point worth flagging: Microsoft’s prose mentions being “authenticated as Site Owner,” yet the published CVSS vector is PR:N (no privileges required), and independent evidence — the Pwn2Own/ZDI-26-412 entry and observed in-the-wild requests — confirms unauthenticated exploitation. Treat it as pre-auth.

Affected and fixed versions

SharePoint editionAffected buildsFixed build (July 2026)
Enterprise Server 2016Below 16.0.5561.100116.0.5561.1001
Server 2019Below 16.0.10417.2017516.0.10417.20175
Subscription EditionBelow 16.0.19725.2043416.0.19725.20434
SharePoint Online (M365)Not affectedN/A
Affected and fixed SharePoint builds for CVE-2026-50522. Source: original article.

Crucial caveat: a security update approved in WSUS or Configuration Manager is not the same as one that is installed. Only the build actually running on each farm server counts — verify it directly with (Get-SPFarm).BuildVersion in the SharePoint Management Shell.

How the exploit chain works

The attack vector is a single unauthenticated HTTP POST to the WS-Federation trust endpoint. The request skeleton below shows the shape of the payload (the serialized gadget itself is redacted):

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>

Mechanically: the payload is a serialized .NET BinaryFormatter object with a gadget chain (for example TypeConfuseDelegate), DEFLATE-compressed and Base64-encoded to fit the cookie field, then wrapped in a SecurityContextToken. When SessionSecurityTokenHandler deserializes it, the chain executes the attacker’s command in w3wp.exe. Public PoCs prove execution by triggering an out-of-band callback. Note that the source advisory deliberately withholds a working exploit and provides detection only.

Am I affected? Quick manual checks

The authoritative check runs on a host you control and asks the farm directly:

# 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, you can fingerprint the advertised build:

# 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

Important caveat: the MicrosoftSharePointTeamServices header reports a minimum build level and can lag the true patch state because of how that value is written during administrative operations. Treat an in-range header as “confirm this,” not the final verdict — verify with (Get-SPFarm).BuildVersion on the host. The header never over-reports risk in a way that would cause you to skip a needed patch.

Nuclei detection template for CVE-2026-50522

The template below is version-based and non-destructive: it reads the public MicrosoftSharePointTeamServices header, extracts the advertised build, and flags builds below the July 2026 fixed levels per product line. It sends no deserialization payload and never touches /_trust/default.aspx.

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

Run it against a single target or a host list:

# 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 matchers identify the product line and fix level, and the extracted build appears in results for immediate triage. Two blind spots to keep in mind: confirm any in-range hit with (Get-SPFarm).BuildVersion, and treat a no-match as inconclusive if a reverse proxy or WAF strips the header.

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

The hard part is rarely writing the check — it is knowing every place the check needs to run. Most organizations lack a clean inventory of exposed SharePoint servers: extranet sites, forgotten project farms, and subsidiary acquisitions routinely miss patch cycles. Sn1per combines discovery and detection in one engine: it enumerates the surface (subdomains, live hosts, services, technologies), fingerprints the running software, runs a curated Nuclei set (including the CVE-2026-50522 template) against what it finds, and persists results in a named workspace.

# 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 '.'

Workspace persistence enables scheduled re-checks via cron or CI/CD, newly stood-up farms get fingerprinted within a run cycle, a correlation layer ranks CVE-2026-50522 findings alongside other weaknesses on the same host, and the self-hosted deployment keeps your target list and scan data inside the perimeter.

Which Sn1per edition fits

CapabilityCommunity EditionProfessional 2026Enterprise
Curated Nuclei set incl. CVE-2026-50522 templateYesYesYes
Discovery + detection engineYesYesYes
ScaleSingle operatorUp to 150 assets, single operatorNear-unlimited, multi-operator
Web UI + scheduled scansNoYesYes
JSON API + SIEM / ticketing exportNoYesYes
Multi-workspace / multi-teamNoNoYes
Self-hosted / on-premYesYesYes
Sn1per edition comparison for CVE-2026-50522 detection. Source: original article.

Remediation and mitigation

1. Patch (the only real fix)

Install the July 2026 SharePoint security update so the running build meets 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 (critical — patching alone is insufficient)

Attackers pull the machine keys in a single request and forge tokens that outlive the patch, so any farm that was internet-exposed during the vulnerability window must rotate keys after patching. Order matters, and the cmdlet distinction is easy to get wrong: Set-SPMachineKey generates a new key, while Update-SPMachineKey only deploys an already-generated key — running the latter alone just re-propagates the existing key an attacker may already have.

# 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 to intercept malicious payloads.
  • Place the farm behind a reverse proxy or WAF that inspects the /_trust/ path for serialized .NET payload patterns.
  • 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

  • Assume nothing — exploitation predates many patch windows.
  • Inspect IIS logs for POST requests to /_trust/default.aspx carrying WS-Federation sign-in responses from unexpected external sources.
  • 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 machine-key compromise, and rotate.

Key Takeaways

  • CVE-2026-50522 is a pre-auth, unauthenticated RCE (CVSS 9.8) in on-prem SharePoint 2016, 2019, and Subscription Edition; SharePoint Online is unaffected.
  • The bug is insecure BinaryFormatter deserialization (CWE-502) in the WIF token handler, reached through a single WS-Federation POST to /_trust/default.aspx.
  • Successful exploitation runs as the SharePoint service account and lets attackers steal ASP.NET machine keys — so patching without key rotation leaves a persistence door open.
  • Verify the installed build with (Get-SPFarm).BuildVersion; a WSUS approval or an in-range MicrosoftSharePointTeamServices header is not proof of patching.
  • A non-destructive Nuclei template can flag vulnerable builds at scale without ever sending a payload; Sn1per can pair that check with attack-surface discovery to catch forgotten farms.
  • It is on the CISA KEV list with public PoCs and active exploitation — treat it as an emergency, and hunt for prior compromise.

Defensive Recommendations

  • Patch immediately to the July 2026 fixed build on every farm server, then confirm with (Get-SPFarm).BuildVersion.
  • Rotate ASP.NET machine keys after patching using Set-SPMachineKey (generate) then Update-SPMachineKey (deploy), and finish with iisreset on every server.
  • Enable AMSI integration on SharePoint 2016/2019 so malicious deserialization payloads can be intercepted.
  • Front the farm with a WAF/reverse proxy that inspects /_trust/ for serialized .NET patterns, and remove internet exposure from auth endpoints that do not need it.
  • Continuously discover exposed SharePoint across subsidiaries and shadow IT, and re-scan on a schedule — a one-time inventory goes stale fast.
  • Threat-hunt IIS logs for anomalous /_trust/default.aspx POSTs and suspicious w3wp.exe child processes, and treat any hit as a key-compromise event.
  • Monitor CISA KEV and enforce the remediation deadline as a hard SLA for internet-facing SharePoint.

Frequently asked questions

What is CVE-2026-50522? A critical, unauthenticated RCE in on-premises Microsoft SharePoint Server caused by insecure BinaryFormatter deserialization (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 the malicious security token and runs code as the SharePoint service account.

Which SharePoint versions are affected? All supported on-premises editions — Enterprise Server 2016 (below 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.

Is it being exploited in the wild? Yes. A public proof-of-concept was released in July 2026 and active exploitation followed within days. CISA added it to the KEV catalog on July 22, 2026 (federal remediation deadline July 25), and attackers are stealing ASP.NET machine keys for persistence.

Why rotate machine keys after patching? The vulnerability lets attackers read the server’s ASP.NET machine keys, which sign and protect authentication tokens. Anyone who captured the keys before patching can forge valid tokens and regain access even after the update is installed. Patching closes the door; rotating the machine keys changes the locks.

Is the Nuclei template safe in production? Yes. It 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 against production targets — just confirm any in-range hit against the farm’s actual build with (Get-SPFarm).BuildVersion.

Conclusion

CVE-2026-50522 is the familiar, dangerous shape of a SharePoint on-prem bug: a legacy deserializer reachable pre-auth, RCE as the service account, and a machine-key theft that turns a one-shot exploit into durable persistence. The response is not complicated, but it has two mandatory halves — patch to the July 2026 build, then rotate machine keys and iisreset the farm — plus the discipline to verify the installed build, hunt for prior access, and keep discovering exposed farms you may have forgotten. A safe, version-based Nuclei template and attack-surface tooling like Sn1per make the “find everything vulnerable” step tractable; the rest is patch hygiene and key rotation done in the right order.

Original text: “CVE-2026-50522: Unauthenticated Deserialization RCE in Microsoft SharePoint Server – Advisory + Nuclei Detection” by xer0dayz (Founder of XeroSecurity) at Sn1perSecurity.

oxfemale Vulnerability research, reverse engineering, and exploit development.
// Discussion