Package Instance

October CMS has Safe Mode Bypass via CSS Preprocessor Compilers
A server-side information disclosure vulnerability was identified in the handling of CSS preprocessor files. Backend users with Editor permissions could craft `.less`, `.sass`, or `.scss` files that leverage the compiler's import functionality to read arbitrary files from the server. This worked even with `cms.safe_mode` enabled.

### Impact
- Potential exposure of sensitive server-side files
- Requires authenticated backend access with Editor permissions
- Only relevant when `cms.safe_mode` is enabled (otherwise direct PHP injection is already possible)

### Patches
The vulnerability has been patched in v3.7.14 and v4.1.10. When `cms.safe_mode` is enabled, `.less`, `.sass`, and `.scss` files can no longer be created, uploaded, or edited across the CMS editor, media manager, and file upload interfaces. All users are encouraged to upgrade to the latest patched version.

### Workarounds
If upgrading immediately is not possible:
- Set `cms.editable_asset_types` config to `['css', 'js']` to remove preprocessor file types from the editor
- Restrict Editor tool access to fully trusted administrators only

- Reported by [Chris Alupului](https://github.com/neosprings)

October CMS Vulnerable to Stored XSS via Branding Styles
A cross-site scripting (XSS) vulnerabilities was identified in October CMS backend configuration forms:

- **Branding and Appearances Styles**
A user with the `Customize Backend Styles` permission could inject malicious HTML/JS into the stylesheet input at
*Settings → Branding & Appearance → Styles*.

A specially crafted input could break out of the intended `<style>` context, allowing arbitrary script execution across backend pages for all users.

---

October CMS: Editor Sub-Permission Bypass for Asset and Blueprint File Operations
Fine-grained sub-permission checks for asset and blueprint file operations were not enforced in the CMS and Tailor editor extensions. This only affects backend users who were explicitly granted `editor` access but had `editor.cms_assets` or `editor.tailor_blueprints` specifically withheld, an uncommon permission configuration. In this edge case, such users could perform file operations (create, delete, rename, move, upload) on theme assets or blueprint files despite lacking the required sub-permission. A related operator precedence error in the Tailor navigation also disclosed the theme blueprint directory tree under the same conditions.

### Impact
- Only exploitable by authenticated backend users with `editor` access who have been specifically denied the `editor.cms_assets` or `editor.tailor_blueprints` sub-permissions
- Does not affect default permission configurations where editor users typically have all sub-permissions granted
- Users without `editor.cms_assets` could manipulate theme asset files (delete, rename, move, upload, create directories)
- Users without `editor.tailor_blueprints` could manipulate blueprint files (delete, rename, move, upload, create directories)
- Users without `editor.tailor_blueprints` could view the theme blueprint navigation tree, disclosing file paths and directory structure

### Patches
The vulnerability has been patched in v3.7.16 and v4.1.16. Fine-grained document type permission checks are now enforced on all asset and blueprint file operation commands, and the navigation node condition logic has been corrected. All users are encouraged to upgrade to the latest patched version.

### Workarounds
- Restrict the `editor` permission to fully trusted administrators only
- Remove the `editor` permission from any user who should not have asset or blueprint management access

October CMS Vulnerable to Stored XSS via Editor and Branding Styles
A cross-site scripting (XSS) vulnerabilities was identified in October CMS backend configuration forms:

- **Editor Settings Markup Styles**
A user with the `Global Editor Settings` permission could inject malicious HTML/JS into the stylesheet input at
*Settings → Editor Settings → Markup Styles*.

A specially crafted input could break out of the intended `<style>` context, allowing arbitrary script execution across backend pages for all users.

---

October CMS: Reflected XSS via DataTable Form Widget
A reflected Cross-Site Scripting (XSS) vulnerability was identified in the backend DataTable widget where a query parameter was rendered without proper output escaping.

### Impact
- Reflected XSS only, no stored/persistent component
- The backend URL prefix is customizable and must be known or guessed by the attacker
- Requires an authenticated backend user to visit a crafted URL
- No direct access is gained without social engineering

### Patches
The vulnerability has been patched in v3.7.16 and v4.1.16. The affected parameter is now properly escaped. All users are encouraged to upgrade to the latest patched version.

### Workarounds
- Use a non-default backend URL prefix (recommended as standard practice)
- Implement a Content Security Policy (CSP) for backend pages

October CMS has Stored XSS in Backend Editor Markup Classes
A stored cross-site scripting (XSS) vulnerability was identified in the Backend Editor Settings. The Markup Classes fields (used for paragraph styles, inline styles, table styles, etc.) did not sanitize input to valid CSS class name characters. Malicious values were rendered unsanitized in Froala editor dropdown menus, allowing JavaScript execution when any user opened a RichEditor.

### Impact
- Stored XSS via editor settings rendered in RichEditor dropdowns
- Could allow privilege escalation if a superuser opens any RichEditor (e.g., editing a blog post)
- Requires authenticated backend access with editor settings permissions
- Triggers on routine content editing operations

### Patches
The vulnerability has been patched in v3.7.14 and v4.1.10. All users are encouraged to upgrade to the latest patched version.

### Workarounds
If upgrading immediately is not possible:
- Restrict editor settings permissions to fully trusted administrators only

### References
- Reported by [Chris Alupului](https://github.com/neosprings)

October CMS has Stored XSS in Event Log Mail Preview
A stored cross-site scripting (XSS) vulnerability was identified in the Event Log mail preview feature. When viewing logged mail messages, HTML content was rendered in an iframe without proper sandboxing, allowing JavaScript execution in the viewer's browser context.

### Impact
- Stored XSS via mail template content rendered in Event Log
- Could allow privilege escalation if a superuser views a malicious log entry
- Requires authenticated backend access with mail template editing permissions
- Requires a superuser to view the specific Event Log entry to trigger

### Patches
The vulnerability has been patched in v3.7.14 and v4.1.10. All users are encouraged to upgrade to the latest patched version.

### Workarounds
If upgrading immediately is not possible:
- Restrict mail template editing permissions to fully trusted administrators only
- Restrict Event Log viewing permissions to minimize exposure

### References
- Reported by [Chris Alupului](https://github.com/neosprings)