Twig sandbox authorization flaw enables database writes in OctoberCMS's October CMS

October is a Content Management System (CMS) and web platform. Prior to 3.7.14 and 4.1.10, a vulnerability was identified in the Twig sandbox security policy that allowed database write operations when cms.safe_mode is enabled. Backend users with Developer permissions could use Twig template markup to execute insert, update, and delete operations on any database table through the query builder, which is included in the sandbox allow-list. This vulnerability is fixed in 3.7.14 and 4.1.10.

• October CMS in the Composer package october/system:
• 3.x branch: versions < 3.7.14 are affected; the identified fix is 3.7.14.
• 4.x branch: versions >= 4.0.0, < 4.1.10 are affected; the identified fix is 4.1.10.
• The described exploitation condition is a deployment with cms.safe_mode enabled and backend users granted Developer permissions. The record does not establish the status of branches outside these ranges.

OctoberCMS's October CMS is affected in the october/system component by a flaw in the Twig sandbox security policy. When cms.safe_mode is enabled, the query builder remains in the sandbox allow-list while database write operations are not fully blocked. An authenticated backend user with Developer permissions can supply Twig template markup to perform insert, update, and delete operations on any database table. This combines an incomplete disallowed-input list with incorrect authorization enforcement, corresponding to CWE-184 and CWE-863 in the record. The fix also blocks insert, update, delete, and truncate operations on query builder and model objects within the Twig sandbox. The available evidence does not identify the exact internal policy rule that was missing or a specific backend endpoint used to submit the template.

The attack path is reachable over the network through the October CMS backend. An attacker needs an authenticated backend account, Developer permissions, and a deployment with cms.safe_mode enabled; the supplied attack properties do not require additional interaction from another user. The record marks public_exploit as false, but real-world exploitation is not confirmed because the known-exploited status is unset. The reviewed sources do not name a specific exploit, campaign, victim, or indicator of compromise.

The primary technical outcome is unauthorized database writing from Twig template markup, including modification or deletion of data in any table through the query builder. Because Developer permissions are required, this is not an unauthenticated attack path and does not by itself demonstrate privilege escalation from an ordinary account. Destructive database operations can compromise application data integrity and may disrupt service if essential tables are affected. The source description focuses on write operations; the available evidence does not independently confirm a read or data-disclosure primitive. The actual damage depends on the application's database privileges and the tables available to the application.

The flaw can permit unauthorized modification or deletion of data in any database table accessible to the application's database account. Depending on the schema, this could corrupt CMS content, business state, accounts, configuration, or operational data, creating recovery and reconciliation work. Destructive or incorrect updates could disrupt application functions if they affect data required for normal operation. Exploitation is constrained by the requirement for authenticated backend access with Developer permissions and by the cms.safe_mode condition. The advisory also states that direct PHP injection is already possible when safe mode is disabled, so disabling safe mode is not a safe mitigation.

1. Upgrade the 3.x branch to exactly 3.7.14, or the 4.x branch to exactly 4.1.10, according to the deployed branch.
2. If an immediate upgrade is not possible, restrict Developer tool access to fully trusted administrators, as recommended by the advisory.
3. Do not use disabling cms.safe_mode as a patch. The vendor source states that this issue is relevant when safe mode is enabled and that direct PHP injection is otherwise already possible.
4. After upgrading, verify the actual installed Composer package version and confirm that Twig sandbox write operations are blocked.
5. If unauthorized data changes are suspected, preserve evidence, compare the database with trusted backups, and recover data through the organization's incident response process. Do not infer that other parallel branches or versions are fixed without separate evidence.

1. Inventory October CMS deployments and determine the exact installed version of the Composer package october/system on each server.
2. Check the cms.safe_mode configuration and identify systems where it is enabled and backend access is available.
3. Review backend accounts with Developer permissions, especially accounts that can edit or execute Twig templates.
4. If backend audit logging or database auditing is available, review Developer template changes and unexpected insert, update, delete, or truncate activity. This is precautionary review, not a vendor-confirmed indicator.
5. Compare critical data, schemas, and trusted backups to identify unauthorized changes in application tables.
6. Do not treat the absence of relevant logs or detected changes as proof that a system is safe.