CVE-2026-46696: Low severity composer/october/system vulnerability
A vulnerability was identified in the Twig sandbox security policy that allowed a chained bypass when cms.safemode is enabled. The Laravel session store was exposed to Twig with unrestricted method access, and raw SQL methods reachable through Eloquent's call forwarding were not blocked across the full builder chain. When combined, a backend user with CMS markup editing access could read arbitrary database values via raw SQL expressions and write to the backend authentication session key, forging a backend session as another existing user.
Scope of impact is narrow. Safe Mode is a niche 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. Standard production deployments do not enable Safe Mode, because under normal October CMS guidance backend access - including markup editing - is restricted to trusted administrators, and direct PHP injection through markup is already possible without Safe Mode in that configuration.
This issue only affects sites that meet all of the following conditions: - cms.safemode is enabled (a deliberate opt-in for demos or untrusted-editor scenarios) - The site has at least one backend user with CMS markup editing access who is not intended to be trusted as a full administrator - The site has at least one existing superuser account whose session the lower-privileged user can impersonate
Impact - Arbitrary read access to database tables, including superuser persistence codes from backendusers, via raw SQL expressions reachable through Eloquent\Model, Eloquent\Builder, or any allowlisted class that call-forwards to a query builder - Forgery of a backend authentication session by writing to the adminauth session key from a Twig template, allowing a markup editor to impersonate an existing superuser - Requires authenticated backend access with CMS markup editing permission AND cms.safemode enabled - Not exploitable when Safe Mode is disabled (direct PHP injection through markup is already possible in that configuration, so Safe Mode is the boundary this issue affects)
Patches The vulnerability has been patched in v3.7.17 and v4.2.21. The Laravel session store is now wrapped in a proxy that exposes only an explicit subset of read/write methods and rejects writes to reserved session key prefixes (adminauth, octoberauth, login, token, and other framework internals). Raw SQL and subquery methods (selectRaw, whereRaw, orderByRaw, joinSub, and related) are now blocked on Query\Builder, Eloquent\Builder, and Eloquent\Model so the blocklist is consistent across the call forwarding chain. All sites that enable cms.safemode are encouraged to upgrade to the latest patched version.
Workarounds If upgrading immediately is not possible: - Restrict CMS markup editing access to fully trusted administrators only - the standard October CMS recommendation for any deployment - Note that disabling cms.safemode is not a workaround; Safe Mode is the boundary this issue affects, and disabling it removes the only sandbox between markup editors and the server
References - Reported by r00tn0b0dy
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
composer/october/systemto a version that resolves this vulnerability.Fixed in 4.2.23 - Upgrade
Upgrade
composer/october/systemto a version that resolves this vulnerability.Fixed in 3.7.17 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 3.7.17 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 4.2.21 - Configuration
Ensure cms.safe_mode is enabled only as part of the protected sandbox boundary; upgrade to v3.7.17 or v4.2.21 to patch the Twig sandbox security policy bypass that affected authenticated backend markup editors.
October CMS (Twig sandbox / Safe Mode) cms.safe_mode = enabled - Compensating control
Restrict CMS markup editing access to fully trusted administrators only (do not grant it to untrusted backend users).
Event History
Frequently Asked Questions
Are typical production deployments exposed?
Generally no. The issue requires cms.safe_mode to be deliberately enabled; standard production deployments do not enable Safe Mode and normally restrict backend markup editing to trusted administrators.
What access would an attacker need?
The attacker must already be a backend user with access to edit CMS markup in a Safe Mode deployment. This is most relevant to demo, multi-tenant, or shared-editor environments that intentionally grant untrusted users markup-editor access.
What could a successful attacker do?
They could use raw SQL expressions to read arbitrary database values and write to the backend authentication session key. This could allow them to forge a backend session as another existing user.