← Back to Feed CACHED · 2026-07-08 02:15:42 · CACHE_KEY CVE-2026-33112
CVE-2026-33112 · CWE-502 · Disclosed 2026-05-12

Deserialization of untrusted data in Microsoft Office SharePoint

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
Do you agree?
01 · The Real Story

A signed-in user hands SharePoint a poisoned lunchbox and the server eats it as SYSTEM

CVE-2026-33112 is an untrusted deserialization flaw (CWE-502) in Microsoft Office SharePoint Server. An authenticated user with at least *contribute* rights on a site can submit a crafted serialized payload — typically via a form field, list item, or workflow parameter — that SharePoint's server-side handlers rehydrate without safe-type gating. The gadget chain executes in the context of the w3wp.exe app pool, which on default installs runs as a domain service account with rights across the farm. Affected: SharePoint Server Subscription Edition, SharePoint Server 2019 (pre-May 2026 CU), and SharePoint Server 2016 (pre-May 2026 CU).

Microsoft's HIGH / 8.8 rating is *approximately* correct but slightly generous on the friction side and slightly stingy on the blast-radius side. PR:L is real — you need a valid account with write access somewhere — but SharePoint farms in the real world hand out contribute rights liberally, and once RCE lands, the service account is typically a domain principal with access to Search, User Profile, Secure Store, and often SQL. We hold the line at HIGH rather than downgrading: the exploitation prerequisite is a phished cookie away, and the role multiplier on collab farms is severe.

"Authenticated SharePoint deser bug — low EPSS, but the blast radius on a collab hub with domain-joined service accounts keeps this HIGH."
02 · The Attack Path

5 steps from start to impact.

STEP 01

Obtain authenticated SharePoint session

Attacker acquires valid credentials or a session cookie for any account with contribute-or-higher rights on at least one site collection. In practice this is achieved via phishing, password spray against exposed OWA/ADFS, or pivot from a compromised endpoint. Tools: evilginx3, EvilnoVNC, or plain Rubeus ticket theft on an internal foothold.
Conditions required:
  • Valid credentials or stolen session token
  • Network reachability to SharePoint front-end (typically internal or via reverse proxy)
Where this breaks in practice:
  • MFA on the SharePoint-fronting IdP blocks most password spray
  • External SharePoint exposure is rare — most farms are intranet-only or fronted by Entra Application Proxy with Conditional Access
Detection/coverage: Entra ID sign-in risk, impossible-travel rules, and IIS log correlation catch anomalous session origins
STEP 02

Enumerate write-capable endpoint

Attacker walks accessible sites to find one where the compromised principal can post list items, upload documents, or trigger a workflow that accepts serialized input. Common vectors are the /lists/, /_layouts/15/, and workflow-init endpoints. SharpSploit and SharePointExploit modules automate the crawl.
Conditions required:
  • Contribute-or-higher permission on at least one site
  • Site with a vulnerable handler surface enabled
Where this breaks in practice:
  • Least-privilege site permissioning limits reachable surface
  • Farms using read-only publishing sites for external users expose no write handler
Detection/coverage: ULS logs, SharePoint audit events for list-item create with anomalous payload size
STEP 03

Deliver deserialization gadget

Attacker crafts a ysoserial.net gadget chain (typically TypeConfuseDelegate or ObjectDataProvider) wrapped in SharePoint's expected serialization envelope and POSTs it to the vulnerable handler. The server-side type resolver rehydrates the object graph and invokes the gadget's constructor / property setters, yielding code execution in the w3wp.exe worker.
Conditions required:
  • Knowledge of the vulnerable parameter and encoding format
  • No egress filtering on the SharePoint tier for the gadget's callback
Where this breaks in practice:
  • May 2026 CU adds SafeControl type allowlisting on the affected handler
  • AMSI-for-.NET on WS2022 flags the classic ysoserial gadgets at load time
Detection/coverage: Defender for Endpoint + AMSI catch the standard gadget families; custom gadgets bypass
STEP 04

Execute as SharePoint app pool identity

Code runs as the pool account — commonly a domain service account like svc_sp_app. From here the attacker dumps the farm passphrase, extracts Secure Store credentials, reads the config DB, and stages further tooling. SharPyShell and Covenant grafts are the typical implants.
Conditions required:
  • Successful gadget execution
  • Outbound network path or on-disk staging capability
Where this breaks in practice:
  • App pool identity hardened per Microsoft baseline (no interactive logon, deny local admin) limits pivot depth
  • Network egress restrictions on the SharePoint tier slow C2 establishment
Detection/coverage: EDR on w3wp.exe child processes, unusual PowerShell / cmd from w3wp, Secure Store API access anomalies
STEP 05

Pivot to farm-wide and domain access

Attacker uses the service account's Kerberos ticket to reach SQL, read/write the config database, extract stored credentials from Secure Store, and — where the SP account is over-privileged — request delegated tickets to other domain services. On misconfigured farms this reaches DA via unconstrained delegation or Secure Store admin creds.
Conditions required:
  • Service account with delegation or excess DB rights
  • Reachability to farm SQL and other domain services
Where this breaks in practice:
  • Properly-tiered service accounts with no delegation confine impact to the SharePoint farm
  • SQL role separation between config DB and content DB reduces credential harvest
Detection/coverage: Kerberos S4U anomalies, honey-account access, SQL audit on Secure Store master key access
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed exploitation as of 2026-07-08. Not on CISA KEV. Historically SharePoint deser bugs (CVE-2019-0604, CVE-2023-29357, CVE-2024-38094) all reached mass-exploitation within 60–120 days of disclosure.
Public PoCNo fully-weaponized public PoC yet. ysoserial.net gadget generation is trivial once the vulnerable parameter is known; expect a Metasploit module within 30–60 days based on historical cadence.
EPSS0.02108 (roughly ~85th percentile). Low absolute value reflects the auth prerequisite, but SharePoint EPSS scores routinely climb 10–50× after first weaponization.
CISA KEVNot listed as of 2026-07-08.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H — network-reachable, low complexity, requires low privileges, no user interaction, full CIA impact. The PR:L is what saved this from being a 9.8.
Affected versionsSharePoint Server Subscription Edition < May 2026 CU (KB5027xxx-series), SharePoint Server 2019 < May 2026 CU, SharePoint Server 2016 < May 2026 CU. SharePoint Online is not affected — Microsoft patches the service directly.
Fixed versionsMay 2026 Patch Tuesday cumulative updates for all three supported on-prem SKUs. No standalone security-only patch — you take the CU.
Exposure telemetryShodan/Censys show ~9k internet-exposed SharePoint on-prem instances globally as of July 2026, down from ~28k in 2023 as Entra App Proxy and M365 migration accelerated. Actual enterprise on-prem footprint is far larger behind VPN/proxy.
Disclosure date2026-05-12 (Microsoft May 2026 Patch Tuesday).
CreditReported by researcher via Trend Micro Zero Day Initiative (ZDI); coordinated disclosure.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to HIGH (8.4/10)

Held at HIGH because the single decisive factor is role multiplier — SharePoint app-pool RCE on a collab-tier farm hands the attacker a domain service account with reach into Secure Store, SQL, and often delegated Kerberos, which is a fleet-adjacent outcome. Authentication is required but is trivially satisfied by any phished or sprayed low-privilege account, so PR:L is a speed bump, not a floor-breaker.

HIGH Vulnerability class and blast radius on typical SharePoint farms
MEDIUM Exploitation timeline — no PoC yet but SharePoint deser bugs weaponize fast
HIGH Patch availability and version boundaries

Why this verdict

  • Role multiplier — SharePoint is a canonical high-value-role component: every enterprise on-prem SharePoint farm runs as a domain service account with cross-farm authority. Chain outcome: farm compromise → Secure Store credential harvest → often domain-account pivot. Floor: HIGH.
  • Authentication prerequisite (PR:L) is weak friction: any user with contribute rights suffices, and SharePoint contribute-rights are routinely handed out to entire org groups. A single phished session token satisfies step 1.
  • No weaponized PoC yet keeps this below CRITICAL: EPSS 0.021 and no KEV mean the 30-day window is not on fire. If a Metasploit module lands or KEV-listing occurs, this jumps to CRITICAL.
  • Internet exposure is narrow but internal exposure is universal: ~9k Shodan-visible instances is small, but on-prem SharePoint remains one of the most common lateral-movement targets in mid-to-large enterprises with hybrid identity.

Why not higher?

No public weaponized exploit, no KEV listing, and no observed campaigns as of 2026-07-08. The auth requirement, while weak, is non-zero — a purely external unauthenticated attacker with no prior foothold cannot land this. CRITICAL is reserved for pre-auth SharePoint RCE or confirmed in-the-wild use.

Why not lower?

Downgrading to MEDIUM would ignore the SharePoint role multiplier — this is the exact class of bug (deserialization → SYSTEM in w3wp → domain pivot) that produced the 2019 and 2023 mass-compromise events. The contribute-rights prerequisite is satisfied by essentially any authenticated user in most enterprises, so real-world friction is much lower than PR:L suggests.

05 · Compensating Control

What to do — in priority order.

  1. Restrict SharePoint contribute/edit rights via emergency ACL review — Deserialization requires write access to a vulnerable handler. Audit site-collection permissions for over-provisioned contribute rights, especially on sites accessible to broad AD groups (Domain Users, All Employees). Deploy within 30 days per the noisgate mitigation SLA for HIGH.
  2. Enforce MFA and Conditional Access on all SharePoint sign-ins — Kills the phishing / password-spray path to step 1. Configure Entra Conditional Access to require MFA + compliant device for all SharePoint access, including internal. Deploy within 30 days.
  3. Rotate and least-privilege the SharePoint app-pool service accounts — Remove Kerberos delegation, deny local admin on member servers, restrict SQL rights to only content DBs needed. Blunts step 5 even if steps 1–4 land. Rotate within 30 days; permanent hardening within 90 days.
  4. Enable AMSI-for-.NET and EDR block-mode on all SharePoint web front-ends — Windows Server 2019+ supports AMSI hooks in the CLR. AMSI catches stock ysoserial.net gadget families. Combined with EDR alerting on w3wp.exe spawning cmd/PowerShell, this is the highest-signal detection layer. Deploy within 30 days.
  5. Egress-filter the SharePoint tier — SharePoint front-ends should not initiate outbound internet connections. A default-deny egress ACL on the WFE VLAN stops the standard C2 callback from step 4.
What doesn't work
  • Perimeter WAF signatures alone — the payload is inside an authenticated, TLS-terminated POST to a legitimate endpoint. Generic WAFs do not inspect deserialization type graphs.
  • Blocking anonymous / external access — SharePoint on-prem is almost never anonymously reachable anyway; this attack presumes an authenticated user, so external hardening does not help.
  • Disabling PowerShell on the SharePoint host — the gadget executes in-process inside w3wp.exe via .NET reflection, not via PowerShell. Constrained Language Mode and PowerShell logging do not stop step 3.
06 · Verification

Crowdsourced verification payload.

Run this on each SharePoint Server (WFE and application role) as a farm admin from an elevated SharePoint Management Shell. Invoke as: .\Check-CVE-2026-33112.ps1 -MinBuildSubscription 16.0.17928.20000 -MinBuild2019 16.0.10416.20000 -MinBuild2016 16.0.5504.1000. Requires local admin on the SharePoint host.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
#requires -Version 5.1
# Check-CVE-2026-33112.ps1
# Detects patched vs vulnerable SharePoint Server on-prem builds for CVE-2026-33112.
# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN

param(
    [string]$MinBuildSubscription = '16.0.17928.20000',
    [string]$MinBuild2019         = '16.0.10416.20000',
    [string]$MinBuild2016         = '16.0.5504.1000'
)

$ErrorActionPreference = 'Stop'

function Compare-Version($a, $b) {
    $va = [Version]$a; $vb = [Version]$b
    return $va.CompareTo($vb)
}

try {
    # Prefer SharePoint snap-in when available
    if (-not (Get-PSSnapin -Name Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue)) {
        Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction Stop
    }
    $farm = Get-SPFarm
    $build = $farm.BuildVersion.ToString()
    Write-Host "[INFO] Detected SharePoint farm build: $build"

    # Product SKU detection
    $product = (Get-SPProduct | Where-Object { $_.ProductName -match 'SharePoint Server' } | Select-Object -First 1).ProductName
    Write-Host "[INFO] Product SKU: $product"

    $minBuild = $null
    if     ($product -match 'Subscription') { $minBuild = $MinBuildSubscription }
    elseif ($product -match '2019')         { $minBuild = $MinBuild2019 }
    elseif ($product -match '2016')         { $minBuild = $MinBuild2016 }
    else {
        Write-Warning "[UNKNOWN] Unrecognized SharePoint SKU: $product"
        exit 2
    }

    if ((Compare-Version $build $minBuild) -ge 0) {
        Write-Host "[PATCHED] Build $build >= required $minBuild for CVE-2026-33112"
        exit 0
    } else {
        Write-Host "[VULNERABLE] Build $build < required $minBuild for CVE-2026-33112"
        exit 1
    }
}
catch {
    Write-Warning "[UNKNOWN] Could not determine SharePoint build: $($_.Exception.Message)"
    exit 2
}
07 · Bottom Line

If you remember one thing.

TL;DR
This is a HIGH-severity SharePoint on-prem deserialization RCE with a weak auth prerequisite and a large role multiplier — treat it as tomorrow's KEV entry, not today's fire drill. Monday morning: (1) inventory all on-prem SharePoint Server 2016 / 2019 / Subscription Edition farms and confirm which are behind Entra App Proxy vs directly reachable; (2) per the noisgate mitigation SLA for HIGH, deploy contribute-rights ACL review, MFA on all SharePoint sign-ins, service-account delegation removal, and SharePoint-tier egress filtering within 30 days; (3) per the noisgate remediation SLA for HIGH, deploy the May 2026 SharePoint CU across the estate within 180 days — but front-load internet-exposed instances into the first 30 days and any farm running as a delegated / over-privileged service account into the first 45. If a public PoC or KEV listing appears, treat as CRITICAL and collapse the mitigation window to hours.

Sources

  1. Microsoft Security Response Center — CVE-2026-33112 advisory
  2. NVD entry for CVE-2026-33112
  3. CISA KEV catalog
  4. FIRST EPSS query
  5. ysoserial.net — .NET deserialization gadget generator
  6. Trend Micro ZDI advisories
  7. Microsoft — Plan for least-privileged SharePoint service accounts
  8. MITRE CWE-502: Deserialization of Untrusted Data
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.