A critical SharePoint remote code execution (RCE) via insecure deserialization is actively exploited. What changed the game: exploitation is now unauthenticated — the bar moved from stolen creds to anyone who can hit the URL. Unpatched, internet-exposed farms are in the scanning pool.
This is not a paper CVE. It’s operational: no phished account required if the chain is reachable anonymously. Increased scanning against SharePoint endpoints is public; treat exposure as time-to-compromise, not a risk register line item.
Why it matters now
- Exploitation in the wild — activity and scanning are public knowledge; the window for “we’ll patch next quarter” is closed.
- CVSS 9.8 — deserialization to RCE is not a “patch when convenient” class of bug.
- Unauthenticated = maximum exposure — any client that can reach the vulnerable endpoint can attempt exploitation; the constraint is network path, not identity.
- SharePoint is crown-jewel adjacent — documents, workflows, often trust to AD. Code execution on the farm is a pivot point.
Technical breakdown (sharp)
Root cause: Insecure deserialization (CWE-502) in SharePoint’s handling of attacker-controlled serialized data.
Attack flow:
- Attacker sends a crafted serialized payload to a vulnerable code path.
- Unsafe deserialization → arbitrary code execution under the SharePoint / IIS worker context (e.g.
w3wp.exe). - From there: run commands, drop tools, read config, steal keys, move laterally.
Impact:
- Full application / host takeover (depending on hardening and privileges).
- Data exfiltration from libraries and backends the app can reach.
- Lateral movement into identity, file, and admin tiers if segmentation is weak.
Attack playbook (realistic)
1. Attacker finds internet-exposed SharePoint (or partner/VPN path with weak controls).
2. No account needed — sends requests to the unauthenticated vulnerable code path (or chains that bypass prior auth assumptions).
3. Delivers malicious serialized content in the crafted request.
4. Achieves RCE on the worker → webshell or in-memory implant.
5. Harvests machine keys, connection strings, service accounts, and SharePoint secrets from disk or memory.
6. Pivots internally — AD, SQL, file shares, email — using trusted farm identity.
That sequence is standard post-2015 enterprise tradecraft. The only variable is whether you patched.
Detection & indicators
- Anomalous deserialization — unusual binary/XML payloads to SharePoint endpoints; unexpected content-types or oversized requests.
- w3wp.exe behavior — child processes (
cmd.exe,powershell.exe), unexpected DLL loads, short-lived spikes. - Outbound from farm servers — C2, RDP, SMB to non-standard peers, DNS tunnels.
- PowerShell encoded commands,
-enc, or script blocks from the app pool identity. - IIS / SharePoint logs + WAF (if any) — correlate 4xx/5xx bursts with new files under web roots.
Mitigation (non-negotiable)
- Patch now — apply the Microsoft security updates for your SharePoint Server build (e.g. January 2026 channel updates referenced by Microsoft; confirm exact KB for your version via MSRC).
- If exposed and unpatched — assume compromise until proven otherwise; hunt, don’t wait for AV to “detect.”
- Rotate secrets — machine keys, service accounts tied to the farm, SQL creds if reachable from the app.
- Isolate — no direct internet exposure unless strictly required; put it behind VPN, zero-trust access, or reverse proxy with strict rules.
- Logging — centralize IIS, Windows, and SharePoint ULS; retain enough history for incident timelines.
In 2026, exposure is exploitation. If your SharePoint is exposed, you’re already in the scanning pool. Patch, verify, hunt — in that order.