A server-side information disclosure vulnerability was identified in the INI settings parser. PHP's parseinistring() function supports ${} syntax for environment variable interpolation. Attackers with Editor access could inject ${APPKEY}, ${DBPASSWORD}, or similar patterns into CMS page settings fields, causing sensitive environment variables to be resolved and stored in the template. These values were then returned to the attacker when the page was reopened.
Impact - Exfiltration of sensitive environment variables (APPKEY, DB credentials, AWS keys, etc.) - Could enable further attacks: database access, cookie forgery, AWS resource access - Requires authenticated backend access with Editor permissions - Only relevant when cms.safemode is enabled (otherwise direct PHP injection is already possible)
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 tool access to fully trusted administrators only - Ensure database and cloud service credentials are not accessible from the web server's network
References - Reported by Proactive Testing Team (PTT)
A stored cross-site scripting (XSS) vulnerability was identified in the SVG sanitization logic. The regex pattern used to strip on event handler attributes could be bypassed using a crafted payload that exploits how the pattern matches attribute boundaries.
Impact - Stored XSS via malicious SVG files uploaded through the Media Manager - Could allow privilege escalation if a superuser views or embeds the malicious SVG - Requires authenticated backend access with media upload permissions (media.library.create) - SVG must be viewed or embedded in a page 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: - Disable SVG uploads by adding svg to the blocked extensions in media configuration - Set media.cleanvectors to true in configuration (enabled by default)
References - Reported by Offensive Security Research Team
Impact
An attacker can request an account password reset and then gain access to the account using a specially crafted request.
- To exploit this vulnerability, an attacker must know the username of an administrator and have access to the password reset form.
Patches
- Issue has been patched in Build 472 and v1.1.5 - Shortened patch instructions
Workarounds
Apply https://github.com/octobercms/library/commit/016a297b1bec55d2e53bc889458ed2cb5c3e9374 and https://github.com/octobercms/library/commit/5bd1a28140b825baebe6becd4f7562299d3de3b9 to your installation manually if you are unable to upgrade.
[Update 2022-01-20] Shortened patch instructions can be found here.
Recommendations
We recommend the following steps to make sure your server stays secure:
- Keep server OS and system software up to date. - Keep October CMS software up to date. - Use a multi-factor authentication plugin. - Change the default backend URL or block public access to the backend area. - Include the Roave/SecurityAdvisories Composer package to ensure that your application doesn't have installed dependencies with known security vulnerabilities.
References
Bugs found as part of Solar Security CMS Research. Credits to: • Andrey Basarygin • Andrey Guzei • Mikhail Khramenkov • Alexander Sidukov • Maxim Teplykh
For more information If you have any questions or comments about this advisory: Email us at hello@octobercms.com
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
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
A sandbox bypass vulnerability was identified in the optional Twig safe mode feature (CMSSAFEMODE). Certain methods on the collect() helper were not properly restricted, allowing authenticated users with template editing permissions to bypass sandbox protections.
Impact - Bypass of Twig sandbox restrictions - Only affects installations with CMSSAFEMODE enabled (disabled by default) - Requires authenticated backend access with CMS template editing permissions
Patches The vulnerability has been patched in v4.1.5 and v3.7.13. All users who have enabled safe mode are encouraged to upgrade to the latest patched version.
Workarounds If upgrading immediately is not possible: - Disable CMSSAFEMODE if untrusted template editing is not required - Restrict CMS template editing permissions to fully trusted administrators only
References - Reported by Łukasz Rybak
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.
---
Impact - Persistent XSS across the backend interface. - Exploitable by lower-privileged accounts with the above permissions. - Potential consequences include privilege escalation, session hijacking, and execution of unauthorized actions in victim sessions.
---
Patches The vulnerability has been patched in v4.0.12 and v3.7.13. Stylesheet inputs are now sanitized to prevent injection of arbitrary HTML/JS.
All users are strongly encouraged to upgrade to the latest patched version.
---
Workarounds If upgrading immediately is not possible: - Restrict the permissions Global Editor Settings to fully trusted administrators only.
This reduces exposure but does not fully eliminate risk.
---
Credits - Reported by Nakkouch Tarek
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.
---
Impact - Persistent XSS across the backend interface. - Exploitable by lower-privileged accounts with the above permissions. - Potential consequences include privilege escalation, session hijacking, and execution of unauthorized actions in victim sessions.
---
Patches The vulnerability has been patched in v4.0.12 and v3.7.13. Stylesheet inputs are now sanitized to prevent injection of arbitrary HTML/JS.
All users are strongly encouraged to upgrade to the latest patched version.
---
Workarounds If upgrading immediately is not possible: - Restrict the permissions Customize Backend Styles to fully trusted administrators only.
This reduces exposure but does not fully eliminate risk.
---
Credits - Reported by Nakkouch Tarek