A vulnerability was identified in the Twig sandbox security policy that allowed a chained bypass when `cms.safe_mode` 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.safe_mode` 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 `backend_users`, 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 `admin_auth` 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.safe_mode` 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 (`admin_auth`, `october_auth`, `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.safe_mode` 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.safe_mode` 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