October System provides the system module for October Content Management System. Prior to versions 3.7.17 and 4.2.21, the backend SessionMaker trait stored widget session state as base64(serialize(...)) and consumed it with unserialize() without an allowedclasses restriction. Any code path that could write to a widget. session key with attacker-controlled bytes could trigger PHP object injection the next time the widget read its session state, allowing instantiation of arbitrary classes and reachable PHP gadget chains. This issue only affects installations running with cms.safemode enabled. Safe Mode is a niche opt-in feature, primarily used for demo installations and multi-tenant or shared-editor scenarios where untrusted users are deliberately granted access to the CMS markup editor. In standard production deployments Safe Mode is off, backend access is restricted to trusted administrators, and a markup editor can already execute arbitrary PHP directly. The session-write path that reaches this sink is gated by the Safe Mode sandbox, so installations without Safe Mode enabled are not exposed. Scope of impact is narrow even with Safe Mode enabled. The standard backend code paths that populate widget session state (search terms, sort options, selected IDs, filter values) wrap the input inside a known array shape before serializing, so user-supplied values never reach unserialize() as a controllable serialized payload. Exploitation requires the Safe Mode session-write path together with a suitable PHP gadget chain reachable from the installed dependency set. The hardening below removes the underlying object-injection sink so the class of issue is closed off regardless. The vulnerability has been patched in v3.7.17 and v4.2.21. Two changes were applied. Backend\Traits\SessionMaker now stores widget session state as plain JSON instead of base64(serialize(...)), eliminating the object-injection sink entirely for new writes. Reads transparently fall back to the legacy format for one upgrade cycle so existing sessions retain their saved widget state. The legacy unserialize() fallback path now sets allowedclasses => false, so even values written before the upgrade cannot instantiate objects. As a workaround, restrict CMS markup editing access to fully trusted administrators only, the standard October CMS recommendation for any deployment.

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 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 stored cross-site scripting (XSS) vulnerability in October CMS Bloghub Plugin v1.3.8 and lower allows attackers to execute arbitrary web scripts or HTML via a crafted payload into the Comments section.

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