SharePoint CVE-2026-20963: Unauthenticated Server Access Explained

Most companies have one place where everything sensitive lives. Strategy documents. Compliance reports. Internal audits. HR files. API keys. For most organisations, that place is SharePoint — the document platform running behind corporate logins, holding years of confidential information.

On March 18, 2026, the US government confirmed that attackers have found a way to walk straight into that room. No password. No invitation. No one needs to click anything. The US cybersecurity agency CISA added CVE-2026-20963 to its official list of vulnerabilities being actively exploited right now — and gave federal agencies until March 21 to patch. That deadline has already passed.

If your organisation runs SharePoint on its own servers and hasn't applied the January 2026 update, consider it an open door.

Root Cause — The Unlocked Door

Here's the simplest way to understand this vulnerability.

When you interact with a SharePoint page — opening a document, clicking a link, submitting a form — the server packages up a record of what you were doing and sends it to your browser. Your browser sends that record back with every click. This is how SharePoint remembers where you are between actions.

The problem: SharePoint reads that record back and acts on it without checking whether it's genuine. An attacker can send a completely fake record containing hidden instructions. When SharePoint reads it, it follows those instructions — before checking whether the sender even has a login.

The attacker doesn't need to break in. They just hand the server a fake note, and the server does exactly what the note says. No authentication check happens until after the damage is done.

What makes this worse is that the attacker doesn't bring any malicious software. They use instructions built from code that already exists inside SharePoint itself — reassembled in a specific order to produce a harmful result. From the server's perspective, it's all legitimate code. That's why it works, and why most security tools don't catch it.

Attack Surface — Who Is Exposed

Any organisation running SharePoint on its own servers — not Microsoft 365 in the cloud — is directly at risk. This is especially common in regulated industries where companies cannot or choose not to store sensitive documents outside their own infrastructure. Banks, financial services firms, legal practices, healthcare organisations, government agencies.

For Indian and Gulf fintech companies specifically, SharePoint often stores RBI and Central Bank compliance drafts, internal security audits, and API documentation. An attacker who accesses your SharePoint server hasn't just breached a file storage system. They've read your business strategy, your risk assessments, and your regulator correspondence.

There's a second, underreported exposure: organisations still running SharePoint 2007, 2010, or 2013. Microsoft ended support for these versions years ago. They are vulnerable to the same attack and will never receive a patch. The only options are upgrading, isolating, or decommissioning.

Exploit Chain — What Happens After the Attack

The attack moves fast and follows a well-documented path.

The request: The attacker sends a single HTTP request — the same kind your browser sends when you click something in SharePoint — to a standard SharePoint web address. The request contains hidden instructions disguised as normal data.

Code runs: SharePoint's server process reads the request and begins processing it. The hidden instructions execute. The attacker now has code running on the server under the identity of the SharePoint service account — the system user that SharePoint runs as.

Why this account matters: In most organisations, the SharePoint service account was set up with broad network access years ago and never reviewed. It often has administrator-level rights across the company network. The attacker just inherited all of those permissions.

Persistent access: The attacker drops a small file — a web shell — into the SharePoint server's folder. This gives them a permanent back door they can use anytime, even after the vulnerability is patched, unless the file is found and removed.

The broader breach: With administrator-level access to the server, the attacker can copy the login credentials of every employee who has recently accessed SharePoint. Those credentials can then be used to access email systems, internal tools, file servers, and anything else on the company network. One unpatched SharePoint server becomes a full network compromise.

The US government described the technical impact of this vulnerability as "total." That's not an exaggeration. From a single HTTP request to complete network access is a documented, automated attack path that takes minutes.

MITRE ATT&CK Mapping

Indicators of Compromise (IOCs)

# CVE-2026-20963 SharePoint RCE — Detection Indicators

# HIGHEST PRIORITY — treat as confirmed breach, not investigation
Alert: w3wp.exe (SharePoint's web process) spawning any of:
  - cmd.exe
  - powershell.exe
  - csc.exe
  - msbuild.exe
  This never happens in normal SharePoint operation.
  Any instance = immediate isolation and incident response.

# Web shell detection
Alert: New or modified .aspx files in SharePoint layouts folder:
  C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\
Alert: Any .aspx file created by w3wp.exe anywhere on the server
Alert: File system changes in web-accessible SharePoint directories
  outside of known update or deployment windows

# Network indicators
Alert: Outbound connection from SharePoint server to unknown external IP
  within 60 seconds of a large POST request to /_layouts/ endpoint
Alert: Unusually large POST request bodies to /_layouts/15/ endpoints
  (malicious payloads are significantly larger than normal page data)

# Credential theft and lateral movement
Alert: LSASS memory accessed by w3wp.exe or its child processes
Alert: SharePoint service account authenticating to systems
  it has no legitimate reason to access
Alert: Spike in authentication attempts from SharePoint server IP
  to domain controllers or internal file servers

# Patch verification
Alert: Any SharePoint server not running January 2026 cumulative update
  — treat as potentially compromised until patched and investigated

SOC Alert Priorities

Alert Priority 1 — w3wp.exe spawning a command prompt or PowerShell means the server is compromised: This is not a false positive to investigate later. SharePoint's server process has no reason to open a command line under normal operation. If your security tools show this happening, isolate the server immediately and start incident response. Every minute of delay gives the attacker more time inside your network.

Alert Priority 2 — Verify patch status on every SharePoint server today: The January 2026 update has been available for two months. Any server not running it is currently vulnerable to this attack. Run your asset inventory now. For any unpatched server that cannot be patched immediately — take it offline or block all external access to it until the patch can be applied.

Alert Priority 3 — Check the SharePoint layouts folder for unknown files: If any of your SharePoint servers were internet-facing and unpatched, assume an attacker may have already been inside and left a back door. Check the layouts folder for any .aspx file that your team didn't deploy. Any unexplained file there should be treated as a web shell.

Alert Priority 4 — Rotate the SharePoint service account password now: Even on patched servers, if the server was previously exposed, the service account credentials may have been copied. Change the password today. Then review what that account has access to — if it holds administrator rights across your network, reduce its permissions to only what SharePoint actually needs.

Alert Priority 5 — Review SharePoint access logs for the last 14 days: CISA confirmed exploitation was already happening before March 18. Check your audit logs for bulk document access or downloads that don't match known users or business activities in the two weeks before today. Unusual access patterns at scale could mean data was already exfiltrated before you knew this vulnerability existed.

What To Do Right Now

Patched (January 2026 update applied): You're protected against the initial attack. Still run the web shell check and rotate the service account password as a precaution. Review logs for unusual access in the past two weeks.

Unpatched and internet-facing: Apply the January 2026 update immediately. If you cannot patch right now, take the server offline or block all external access to it. Do not leave it running and connected to the internet.

Running SharePoint 2007, 2010, or 2013: No patch exists. Isolate these servers from all external and untrusted network access immediately. The only permanent fix is upgrading to a supported version or decommissioning.

This attack follows the same pattern we've been tracking all month — attackers gaining access through systems organisations trust completely, then using that trust to reach everything else:

→ The Ghost Attack: How Hackers Are Stealing Indian Fintech Sessions After MFA Already Passed

→ Microsoft Patch Tuesday March 2026: 79 Fixes, One SQL Flaw That Hands Attackers Your Database

The ZyberWalls Perspective

SharePoint is not a peripheral system. It is where organisations store what they know — their strategies, their risks, their secrets. A breach of SharePoint is a breach of institutional memory.

What makes this vulnerability particularly hard to excuse is the timeline. The patch was released on January 13. CISA confirmed active exploitation on March 18. Any organisation still running unpatched SharePoint on March 21 had sixty-seven days to act and didn't.

That gap — between patch availability and actual patching — is where almost every major breach lives. Attackers don't need zero-days when defenders leave known vulnerabilities open for months.

The three steps are simple. Patch. Rotate the service account password. Check the logs. In that order, today.