Vulnerability in CMS 12 shell module configuration

Introduction

A potential security vulnerability has been identified in Optimizely CMS 12, triggered by a certain shell module configuration. To be vulnerable the application needs to fulfil these conditions:

• Use EPiServer.CMS and/or EPiServer.CMS.UI.Core packages of version 12.0.0 or higher.
• Have a module.config file in the root folder of the deployed application. Module.config files inside separate module directories/zips are not affected, only if the file is in the application root.
• Have the clientResourceRelativePath attribute present on the <module> element in the module.config file and the clientResourceRelativePath attribute set to an empty string.

If all these conditions are met there is a potential vulnerability allowing an attacker using an authenticated account to access sensitive data in the application.

Risk

The risk of this vulnerability is high. Mitigation is in place for all DXP service customers.

Affected versions

All versions higher than 12.0.0 of EPiServer.CMS.UI.Core. Note that the project might not be referencing this package directly, but rather it being a transitive dependency of for example the EPiServer.CMS package of the same version.

Remediation

The underlying issue has been fixed in CMS-30098. Update to version 12.22.8 or later of the EPiServer.CMS (or EPiServer.CMS.UI or EPiServer.CMS.UI.Core, depending on which package you reference directly) to receive this fix.

As an alternative workaround if you cannot take an update right now, edit the module.config to remove the clientResourceRelativePath completely instead of having it set to an empty string. 

Depending on the setup of the specific shell module and module.config, either of these changes might mean you also need to change the location of files in the paths referenced by the module.config, and/or change how paths to those files are resolved in the application to match.

These module files are related to editor customizations, scripts and stylesheets used in shell modules, so make sure to test such customizations. Please contact support if you run into a scenario you cannot solve.

Questions

Please contact application support at support@optimizely.com

Risk definitions

Low – little to no potential impact on Optimizely or customer environments/data. Vulnerability has low exploitability, for example: requirement for local or physical system access, zero reachability to/executability within Optimizely products/code.

Medium – some potential impact on Optimizely or customer environments/data. Vulnerability has medium exploitability, for example: requirement to be located on the same local network as the target, requirement for an individual to be manipulated via social engineering, requirement for user privileges, vulnerability achieves limited access to Optimizely products/code.

High – high potential impact on Optimizely or customer environments/data.  Vulnerability has high exploitability, for example:  achieves high level access to Optimizely products/code, could elevate privileges, could result in a significant data loss or downtime.

Critical – very significant potential impact on Optimizely or customer environments/data.  Vulnerability has very high exploitability, for example: achieves admin/root-level access to Optimizely products/code.  Vulnerability does not require any special authentication credentials/knowledge of Optimizely products/environments.