CVE-2026-45454 — Microsoft SharePoint Server Upload Page Folder Path Traversal to Remote Code Execution

1. Overview

A path traversal vulnerability exists in the SharePoint Server file upload page (Upload.aspx). The UploadPage.CurrentFolder property resolves the upload destination from the user-supplied RootFolder query string parameter without validating that the resolved folder belongs to the document library specified by the List parameter. An authenticated attacker with upload permissions to one document library can craft a request that uploads files to a different, restricted document library on the same site — including the Master Page Gallery (_catalogs/masterpage).

When the SharePoint web application has PageParserPaths configured to allow server-side script in the Master Page Gallery — a common configuration in deployments with custom branding or master pages — the attacker can upload an ASPX webshell that executes arbitrary operating system commands under the w3wp.exe application pool identity. This escalates the vulnerability from a path traversal to full Remote Code Execution.

Microsoft addressed this vulnerability by adding a ParentListId ownership check to the CurrentFolder property.

2. Vulnerability Type

3. Severity

CVSS 3.1 (from CVRF advisory)

Note: Microsoft’s advisory vector shows C:H/I:N (confidentiality impact). Our confirmed exploit demonstrates I:H/C:N (integrity impact — unauthorized file write to a restricted document library) with subsequent code execution. The CVSS vector may reflect a different variant fixed by the same KB.

Our Assessment (CVSS 4.0)

SC:H/SI:H reflects the subsequent impact of code execution on the operating system when PageParserPaths is configured. The base VI:H reflects the unconditional ability to write files to arbitrary document libraries. Microsoft rates exploitation as “Less Likely” with no known active exploitation (CVRF June 2026).

4. Affected Products

Affected Products

Tested Environment (Vulnerable)

Tested Environment (Patched)

Patch Matrix

SharePoint Server 2019

SharePoint Server 2016

SharePoint Server Subscription Edition

5. Root Cause Analysis

5a. Detailed Description

SharePoint’s Upload.aspx page (code-behind: UploadPage in microsoft.office.policy.pages.dll) handles file uploads to document libraries. The page accepts two query string parameters:

• List — GUID of the target document library (used for permission checks)
• RootFolder — Server-relative URL of the destination folder

The CurrentList property resolves the List parameter to an SPDocumentLibrary object. SharePoint checks that the current user has AddListItems permission on this library (via LayoutsPageBase.RightsRequired).

The CurrentFolder property resolves the RootFolder parameter to an SPFolder object via SPWeb.GetFolder():

// UploadPage.CurrentFolder (pre-patch)
// microsoft.office.policy.pages.dll 16.0.10337.12109 (SP2019) / 16.0.5535.1000 (SP2016)

protected SPFolder CurrentFolder
{
    get
    {
        if (m_folder == null)
        {
            // RootFolder resolved via GetFolder -- NO ownership check
            m_folder = PrivateWeb.GetFolder(CurrentFolderServerRelativeUrl);
        }
        return m_folder;
    }
}

protected virtual string CurrentFolderServerRelativeUrl
{
    get
    {
        if (m_folderUrl == null)
        {
            string value = SPRequestParameterUtility.GetValue<string>(
                this.Request, "RootFolder");  // <-- user-controlled
            if (!string.IsNullOrEmpty(value))
                m_folderUrl = value;
            else
                m_folderUrl = CurrentList.RootFolder.ServerRelativeUrl;
        }
        return m_folderUrl;
    }
}

The vulnerability is that GetFolder() resolves ANY valid folder URL on the site — it does not check that the folder belongs to the library specified by List. An attacker can set List to a library they have upload permissions on (passing the permission check) while setting RootFolder to a folder in a completely different library (redirecting the actual upload).

When OnSubmit() processes the file upload, it calls UploadFile() which adds the file to CurrentFolder.Files — the traversed folder, not the authorized library’s folder.

5b. Vulnerable Assembly and Call Stack

microsoft.office.policy.pages.dll 16.0.10337.12109 (SP2019) / 16.0.5535.1000 (SP2016):

// CurrentFolderServerRelativeUrl -- reads RootFolder from query string
// No validation that the folder belongs to CurrentList
string value = SPRequestParameterUtility.GetValue<string>(this.Request, "RootFolder");
if (!string.IsNullOrEmpty(value))
    m_folderUrl = value;  // attacker-controlled path

// CurrentFolder -- resolves the URL to any folder on the site
m_folder = PrivateWeb.GetFolder(CurrentFolderServerRelativeUrl);

// UploadFile -- adds file to the traversed folder
file = CurrentFolder.Files.Add(leafName, httpPostedFile.InputStream, val2);

Call Stack:

UploadPage.OnSubmit()
  UploadPage.UploadFile()
    UploadPage.UploadFile(HttpPostedFile, ...)
      SPFolder.Files.Add()        // file added to traversed folder
        <- CurrentFolder          // resolves RootFolder without ownership check
          <- PrivateWeb.GetFolder(CurrentFolderServerRelativeUrl)
            <- RootFolder query param (attacker-controlled)

5c. Fix (Patched Version)

The patch adds two validation checks to the CurrentFolder property getter:

// UploadPage.CurrentFolder (patched)
// microsoft.office.policy.pages.dll 16.0.10417.20153 (SP2019) / 16.0.5556.1000 (SP2016)

protected SPFolder CurrentFolder
{
    get
    {
        if (m_folder == null)
        {
            // [NEW] Null list check
            if (CurrentList == null)
            {
                // ULS tag 495502807
                throw new ArgumentException(
                    "RootFolder parameter is being resolved but no target list is set.");
            }

            m_folder = PrivateWeb.GetFolder(CurrentFolderServerRelativeUrl);

            // [NEW] Parent list ownership check
            if (m_folder.ParentListId != CurrentList.ID)
            {
                // ULS tag 495502806: "Possible folder traversal attempt"
                throw new ArgumentException(
                    "Possible folder traversal attempt.");
            }
        }
        return m_folder;
    }
}

5d. Impact

The vulnerability has two tiers of impact:

Tier 1 — Unconditional: Arbitrary File Upload to Restricted Libraries. An authenticated attacker with Contribute permissions on any document library can upload arbitrary files to any other document library on the same SharePoint site, regardless of whether they have permissions on the target library. This was demonstrated by uploading a file with List pointing to “Documents” while RootFolder pointed to the Master Page Gallery — the file appeared in the Master Page Gallery.

Tier 2 — Conditional: Remote Code Execution via Webshell. When the SharePoint web application’s web.config includes a <PageParserPath> entry that enables AllowServerSideScript for /_catalogs/masterpage/* (a common configuration in production deployments with custom branding), the attacker can upload an ASPX webshell to the Master Page Gallery. SharePoint compiles and executes ASPX files from this location as server-side code, allowing the attacker to run arbitrary OS commands under the w3wp.exe application pool identity.

The RCE was confirmed on SharePoint Server 2019: whoami returned the application pool identity, and full command execution (hostname, ipconfig, etc.) was demonstrated.

5e. RCE Attack Chain

1. Attacker has Contribute on "Documents" library
2. GET  Upload.aspx?List={Documents_GUID}&RootFolder=/_catalogs/masterpage
3. POST webshell.aspx to the same URL (traversal upload)
4. File lands in /_catalogs/masterpage/webshell.aspx
5. GET  /_catalogs/masterpage/webshell.aspx?cmd=whoami
6. SharePoint compiles ASPX → server-side code execution
7. Output: application pool identity

SafeMode Considerations:

SharePoint’s SafeMode page parser blocks inline code blocks (<% %>, <script runat="server">) in pages stored in the content database by default. However:

• The <%@ Assembly %> and <%@ Register %> directives are accepted on unpatched systems (the patch introduces BlockUnsafeDirectives to restrict these).
• Safe controls (e.g., asp:Label, DataFormWebPart) render and execute in SafeMode.
• When PageParserPaths is configured for /_catalogs/masterpage/* with AllowServerSideScript="true", full inline code execution is permitted. This configuration is common in SharePoint deployments that use custom master pages or branding.

6. Proof-of-Concept

6a. PoC Code

Download exploit_upload_traversal.py (enterprise email verification required)

Responsible disclosure: The RCE proof-of-concept (exploit_rce_masterpage.py) is being withheld for 30 days after patch release to give administrators time to apply KB5002874 / KB5002880. The path traversal PoC and the full technical description of the RCE chain (Sections 5d–5e) are available immediately to support detection and prioritization.

6b. Reproduce Instructions — Path Traversal

Prerequisites:

• SharePoint Server with vulnerable microsoft.office.policy.pages.dll (tested on SP2019)
• Two document libraries on the same SharePoint site (e.g., “Documents” and “Restricted Documents”)
• An authenticated user with Contribute permissions on the source library
• Python 3.10+ with requests and requests_ntlm
• Network access to SharePoint’s /_layouts/15/Upload.aspx

Reproduction Steps:

1. Run the path traversal PoC:

   uv run exploit_upload_traversal.py --target http://sharepoint.example.com --user DOMAIN\\user --password <pass>
   

2. The script:

   • Retrieves the GUID of “Documents” (source library)
   • GETs Upload.aspx?List={Docs_GUID}&RootFolder=/Restricted Documents to extract form tokens
   • POSTs a file upload form to the same URL
   • Verifies the file appeared in “Restricted Documents”

3. On vulnerable servers, the file traversal_proof.txt appears in “Restricted Documents” despite the List parameter pointing to “Documents”.

4. On patched servers, the upload fails with an ArgumentException (“Possible folder traversal attempt”) and no file is created.

6c. Reproduce Instructions — Remote Code Execution

Additional Prerequisites:

• The SharePoint web application’s web.config must include:

  <PageParserPaths>
    <PageParserPath VirtualPath="/_catalogs/masterpage/*"
                    CompilationMode="Always"
                    AllowServerSideScript="true"
                    IncludeSubFolders="true" />
  </PageParserPaths>
  

  This is a common configuration for deployments using custom master pages.

Reproduction Steps:

1. Run the RCE PoC:

   uv run exploit_rce_masterpage.py \
     --target http://sharepoint.example.com \
     --user DOMAIN\\user --password <pass> \
     --source-lib Documents --payload canary
   

2. The script:

   • Uses the path traversal to upload an ASPX webshell to /_catalogs/masterpage/
   • Browses to the uploaded page to trigger server-side compilation
   • Extracts server information (machine name, identity, process ID) or executes a command

3. For command execution:

   uv run exploit_rce_masterpage.py \
     --target http://sharepoint.example.com \
     --user DOMAIN\\user --password <pass> \
     --payload inline --cmd "whoami & hostname"
   

6d. Test Results

Path Traversal

Remote Code Execution (with PageParserPaths configured)

6e. Patched System Verification

The same PoC was executed against SharePoint Server 2019 patched with KB5002874 (June 2026). The CurrentFolder property’s new ParentListId check detected the mismatch between the resolved folder’s parent list and the List parameter. The upload completed without error but the file did not appear in the target library. Zero files were created in the Master Page Gallery.

7. Detection

Note: The detection rules below are provided as a starting point. Validate and tune them in your own environment before deploying to production.

7a. Network-Based Detection

Signature-Based Detection

The attack is delivered via HTTP GET + POST to /_layouts/15/Upload.aspx. The distinctive pattern is a mismatch between the List and RootFolder query parameters: List contains a GUID for one library while RootFolder contains a path belonging to a different library. Detection can focus on RootFolder values that reference _catalogs/masterpage or other sensitive catalog paths.

Suricata Rules

# Detect SharePoint Upload.aspx traversal to Master Page Gallery (RCE vector)
alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"CVE-2026-45454 SharePoint Upload Path Traversal to Master Page Gallery"; \
  flow:to_server,established; \
  content:"Upload.aspx"; http_uri; \
  content:"List="; http_uri; \
  content:"RootFolder="; http_uri; \
  content:"_catalogs"; http_uri; \
  reference:cve,2026-45454; \
  classtype:web-application-attack; \
  sid:2026454541; rev:2;)

# Detect SharePoint Upload.aspx with potentially mismatched List/RootFolder (broader)
alert http $EXTERNAL_NET any -> $HOME_NET any (msg:"CVE-2026-45454 SharePoint Upload Path Traversal - suspicious RootFolder"; \
  flow:to_server,established; \
  content:"Upload.aspx"; http_uri; \
  content:"List="; http_uri; \
  content:"RootFolder="; http_uri; \
  pcre:"/RootFolder=[^&]*(?:\/[A-Z][^\/&]+)/Ui"; \
  reference:cve,2026-45454; \
  classtype:web-application-attack; \
  sid:2026454542; rev:1;)

Byte Offset Reference (HTTP Request)

7b. Host-Based Detection

Patch Verification

Known Vulnerable Binary Hashes

PowerShell — Check Binary Version

$dll = Get-Item "C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\ISAPI\microsoft.office.policy.pages.dll" -ErrorAction SilentlyContinue
if ($dll) {
    $ver = [Version]$dll.VersionInfo.FileVersion
    $hash = (Get-FileHash $dll.FullName -Algorithm SHA256).Hash
    Write-Host "File Version : $ver"
    Write-Host "SHA256       : $hash"
    # SP2019 threshold
    if ($ver -ge [Version]"16.0.10000.0" -and $ver -lt [Version]"16.0.10417.20153") {
        Write-Host "[!] VULNERABLE — SP2019 DLL predates KB5002874 fix" -ForegroundColor Red
    }
    # SP2016 threshold
    elseif ($ver -lt [Version]"16.0.5556.1000" -and $ver -lt [Version]"16.0.10000.0") {
        Write-Host "[!] VULNERABLE — SP2016 DLL predates KB5002880 fix" -ForegroundColor Red
    }
    else {
        Write-Host "[*] Patched — file version is at or above the fix" -ForegroundColor Green
    }
}

PowerShell — Check Installed KB

Get-HotFix -Id KB5002874,KB5002880 -ErrorAction SilentlyContinue |
    Format-Table HotFixID, InstalledOn -AutoSize

ULS Log Monitoring (Post-Patch)

On patched servers, exploitation attempts are logged in the SharePoint ULS logs with these trace tags:

Get-Content "C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\LOGS\*.log" |
    Select-String "49550280[67]"

8. References