octobercms October CMS Twig sandbox escape enables arbitrary PHP execution

October is a Content Management System (CMS) and web platform to assist with development workflow. An authenticated backend user with the editor.cms_pages, editor.cms_layouts, or editor.cms_partials permissions who would normally not be permitted to provide PHP code to be executed by the CMS due to cms.safe_mode being enabled can write specific Twig code to escape the Twig sandbox and execute arbitrary PHP. This issue has been patched in 3.4.15.

• October CMS, package october/system: versions >= 3.0.0, < 3.4.15 are affected.
• The advisory identifies 3.4.15 as patched.
• The status of releases outside the supported affected range is not established by this record. Do not infer that every later or parallel release branch has been verified as unaffected.

October CMS uses Twig sandboxing and cms.safe_mode to restrict backend users who should not be able to provide PHP for CMS execution. An authenticated backend user with any of the editor.cms_pages, editor.cms_layouts, or editor.cms_partials permissions can write specific Twig code through the corresponding administrative surfaces. That code escapes the Twig sandbox and causes arbitrary PHP to execute, which is a code-injection condition classified as CWE-94. The normalized attack characterization indicates network reachability, low attack complexity, high privileges required, and no additional user interaction. The available evidence does not disclose the specific Twig syntax, vulnerable code path, or patch implementation details.

The flaw is reachable through the backend over the network. An attacker must authenticate and hold at least one of the editor.cms_pages, editor.cms_layouts, or editor.cms_partials permissions, so this is not an unauthenticated entry point. The record characterizes the required privileges as high, the attack complexity as low, and user interaction as unnecessary. The record does not establish active exploitation, a public exploit, or ransomware use.

Arbitrary PHP execution can potentially compromise the confidentiality, integrity, and availability of the October CMS environment. If the CMS process can access databases, filesystems, secrets, or network resources, those resources may also be exposed or altered, but the record does not identify the specific reachable resources. The changed-scope assessment indicates that effects may cross the initial CMS security boundary, although the exact boundary is not described. Because authenticated backend access is required, this is an escalation of what a limited content-management user can do rather than an unauthenticated entry point. The record does not confirm a particular data exposure or service outage.

Successful exploitation can give an authenticated backend user arbitrary PHP execution in the CMS context. This could allow modification of application-controlled content or code, access to data available to the CMS process, or service disruption, but the exact post-exploitation reach is not documented. The risk is especially relevant where cms.safe_mode is relied on to separate content-management duties from PHP-capable administration. The precondition remains significant because the attacker must already have backend authentication and one of the specified permissions.

1. Upgrade affected October CMS or october/system installations in the >= 3.0.0, < 3.4.15 range to 3.4.15, the release identified as patched.
2. If patching is not immediately possible, remove editor.cms_pages, editor.cms_layouts, and editor.cms_partials from untrusted backend users. Treat this as temporary mitigation, not a substitute for the patch.
3. Review role assignments and the cms.safe_mode configuration. The advisory's risk scenario specifically concerns deployments that rely on safe mode to prevent these users from writing and executing PHP.
4. After the change, verify the package version across all instances and re-check backend permissions so that no affected deployment remains overlooked.

1. Inventory every October CMS or october/system deployment and compare the installed version with the affected range.
2. Check the cms.safe_mode configuration and identify environments that rely on it to prevent backend users from executing PHP.
3. Enumerate accounts and roles with editor.cms_pages, editor.cms_layouts, or editor.cms_partials, especially accounts that are not intended to manage PHP.
4. Review available audit records for those accounts modifying CMS pages, layouts, or partials, and for unusual Twig content. This is a precautionary review, not a confirmed indicator.
5. The available evidence does not define a specific log signature or IOC. Failure to find matching records does not prove that a deployment is safe.