The 'b' Key to the Kingdom: Sitecore Hardcoded Credentials

Enterprise CMS solutions like Sitecore are architectural behemoths. They are designed to manage content for some of the largest organizations on the planet, consisting of complex pipelines, databases, and authentication providers. When you install such a system, you aren't just copying files; you are hydrating a massive ecosystem.

Part of this hydration process involves the 'Core' database, which manages system settings, users, and security configuration. In the shift to version 10.1, Sitecore modernized how they deploy this database using DACPAC (Data-Tier Application Package) files. Think of a DACPAC as a vacuum-sealed snapshot of a database schema and its default data.

But here is the problem with snapshots: if you take a picture of your house while the back door is unlocked, every house built from that blueprint will have the back door unlocked. In Sitecore's case, they didn't just leave a door unlocked; they left a key under the mat. And the key was the letter 'b'.

During the analysis of Sitecore.Core.dacpac, researchers at watchTowr Labs noticed something peculiar in the dbo.aspnet_Membership table. This table holds the legacy ASP.NET Membership credentials. Among the rows of data was a user account named sitecore\ServicesAPI.

Now, ServicesAPI sounds like an internal service account—something that should probably be disabled or have a 64-character random password. Instead, the password hash stored in the database corresponded to a single character: 'b'.

Why 'b'? Veterans of the Sitecore ecosystem might chuckle. In the ancient days of Sitecore (think version 6 or 7), the default password for the admin account was often 'b'. It seems that during the creation of the version 10.1 master database image, a developer or a migration script carried this legacy credential forward, baking it into the installer. Because DACPACs are binary deployments, this hardcoded credential wasn't visible in plain text config files, allowing it to slip past code reviews and into production environments for nearly four years.

You might be thinking, "So what? It's a service account with no roles." And you would be half-right. If you try to log into the main Sitecore shell with this account, the application logic usually kicks you out. The Sitecore.Owin.Authentication pipeline has a specific processor that checks if you are an administrator or a specific client user.

However, security is often a game of layers, and the outer layer is usually IIS and web.config rules. Many sensitive directories in Sitecore (like /sitecore/admin or /sitecore/shell) are protected by standard ASP.NET authorization rules:

<authorization>
  <deny users="?" />
</authorization>

The ? represents anonymous users. To get past this check, you don't need to be an admin; you just need to be authenticated. By sending a POST request to the authentication API with the username ServicesAPI and the password b, the server issues a valid .AspNet.Cookies session cookie.

This cookie is the golden ticket. It tells IIS, "I am a known user." IIS lets the request through to the underlying ASPX files. Even if the Sitecore application layer eventually says "Hey, you don't have permission to view this specific page," you have already breached the perimeter. You are now inside the authenticated attack surface, where much more dangerous bugs live.

Exploiting this is embarrassingly simple. No memory corruption, no race conditions, just a polite request to the login API. Here is how an attacker creates a session:

1. Target: The ItemService authentication endpoint at /sitecore/api/ssc/auth/login.
2. Payload: A JSON object containing the credentials.

POST /sitecore/api/ssc/auth/login HTTP/1.1
Host: target.com
Content-Type: application/json
 
{
  "domain": "sitecore",
  "username": "ServicesAPI",
  "password": "b"
}

If the server responds with a 200 OK and a Set-Cookie header containing .AspNet.Cookies, the game is effectively over. The attacker can now take that cookie and browse to endpoints that were previously returning 403 Forbidden or 302 Redirect to login.

While CVE-2025-34509 is ostensibly just an authentication bypass, it is rarely used alone. It is the prerequisite for CVE-2025-34510, a Zip Slip vulnerability in Upload2.aspx. That file is protected by the web.config rule mentioned earlier. Without the 'b' password, the attacker can't reach the upload handler. With it, they can upload a web shell and achieve full Remote Code Execution.

The CVSS score of 7.5 might seem modest because it's technically "only" a privilege escalation to a low-privilege user. Do not be fooled. In the context of Sitecore, this is a gateway drug to total compromise.

Once an attacker has bypassed the initial authentication check, they expose the soft underbelly of the CMS—administrative tools, debugging handlers, and legacy uploaders that were never meant to be exposed to the public internet. The specific combination of CVE-2025-34509 (Auth Bypass) and CVE-2025-34510 (File Write) allows an unauthenticated attacker to execute code as the IIS AppPool user, which often has modify rights to the webroot.

From there, data exfiltration is trivial. Customer data, marketing strategies, and user credentials stored in the SQL database are open for the taking. For a platform designed to host global brands, the reputational damage is catastrophic.

If you are running Sitecore 10.1 through 10.4, you are likely vulnerable unless you manually changed this password previously. The official patch from Sitecore updates the DACPACs for future installs, but it might not automatically fix existing databases.

Immediate Remediation Steps:

1. Change the Password: Log in to the Sitecore Desktop, open the User Manager, find sitecore\ServicesAPI, and change the password to a strong, random string. Alternatively, execute a SQL update against the Core database aspnet_Membership table (though UI is safer).
2. Apply the Patch: Install the relevant hotfix (e.g., KB1003667) to ensure future instances or re-deployments are secure.
3. Network Segmentation: Restrict access to /sitecore/admin and /sitecore/api endpoints. These should not be exposed to the open internet. Use WAF rules to block external access to these paths.

> [!NOTE] > Changing the password for ServicesAPI does not break core functionality in a standard setup, as this account is largely a vestigial artifact or used for specific internal service calls that can be reconfigured.