Cybersecurity researchers have disclosed three security flaws in the popular Sitecore Experience Platform (XP) that could be chained to achieve pre-authenticated remote code execution.
Sitecore Experience Platform is an enterprise-oriented software that provides users with tools for content management, digital marketing, and analytics and reports.
The list of vulnerabilities, which are yet to be assigned CVE identifiers, is as follows –
- Use of hard-coded credentials
- Post-authenticated remote code execution via path traversal
- Post-authenticated remote code execution via Sitecore PowerShell Extension
watchTowr Labs researcher Piotr Bazydlo said the default user account “sitecoreServicesAPI” has a single-character password that’s hard-coded to “b.”
While the user has no roles and permissions assigned in Sitecore, the attack surface management firm found that the credentials could be alternately used against the “/sitecore/admin” API endpoint to sign in as “sitecoreServicesAPI” and obtain a valid session cookie for the user.
“While we can’t access ‘Sitecore Applications’ (where a significant portion of functionality is defined) as the ServicesAPI has no roles assigned, we can still: (1) Access a number of APIs, and (2) Pass through IIS authorization rules and directly access some endpoints,” Bazydlo explained.
This, in turn, opens the door to remote code execution via a zip slip vulnerability that makes it possible to upload a specially crafted ZIP file via the “/sitecore/shell/Applications/Dialogs/Upload/Upload2.aspx” endpoint and causes the archive’s contents (e.g., a web shell) to be written to the webroot directory.
The entire sequence of actions is listed below –
- Authenticate as the “sitecoreServicesAPI” user
- Access Upload2.aspx
- Upload a ZIP file, which contains a web shell called //../<web_shell>
- When prompted, check the Unzip option and complete the upload
- Access the web shell
The third vulnerability has to do with an unrestricted file upload flaw in PowerShell Extensions that can also be exploited as the “sitecoreServicesAPI” user to achieve remote code execution through the “/sitecore%20modules/Shell/PowerShell/UploadFile/PowerShellUploadFile2.aspx” endpoint.
watchTowr pointed out that the hard-coded password originates from within the Sitecore installer that imports a pre-configured user database with the ServicesAPI password set to “b.” This change, the company said, went into effect starting version 10.1.
This also means that the exploit chain only works if users have installed Sitecore using installers for versions ≥ 10.1. Users are likely not impacted if they were previously running a version prior to 10.1 and then upgraded to a newer vulnerable version, assuming the old database is being migrated, and not the database embedded within the installation package.
With previously disclosed flaws in Sitecore XP coming under active exploitation in the wild (CVE-2019-9874 and CVE-2019-9875), it’s essential that users apply the latest patches, if not already, to safeguard against potential cyber threats.
“By default, recent versions of Sitecore shipped with a user that had a hard-coded password of ‘b.’ It’s 2025, and we can’t believe we still have to say this, but that’s very bad,” Benjamin Harris, CEO and founder of watchTowr, told The Hacker News in a statement.
“Sitecore is deployed across thousands of environments, including banks, airlines, and global enterprises – so the blast radius here is massive. And no, this isn’t theoretical: we’ve run the full chain, end-to-end. If you’re running Sitecore, it doesn’t get worse than this – rotate creds and patch immediately before attackers inevitably reverse engineer the fix.”
