Winter CMS versions before 1.2.13 contain an incomplete fix for a Twig sandbox escape vulnerability in System\\Twig\\SecurityPolicy that allows authenticated backend users with template-editing permissions to bypass sandbox restrictions. Attackers can exploit method forwarding through Eloquent models and query builders using methods like saveQuietly(), deleteQuietly(), increment(), decrement(), and newQuery() to read and modify arbitrary database records, execute arbitrary SQL, and achieve remote code execution by injecting PHP into template code sections.

Winter CMS is a content management system built on the Laravel PHP framework. Prior to 1.2.14, the ImportExportController behavior applies userHasAccess() only to the import() and export() page actions, while Backend\Classes\Controller::execAjaxHandlers() dispatches onImport(), onImportLoadForm(), onImportLoadColumnSampleForm(), onExport(), and onExportLoadForm() before those gated actions run, and the separately reachable download() action also lacks the granular export check. An authenticated backend user with a valid session and coarse access through $requiredPermissions, but without the configured import[permissions] or export[permissions], can use the import handlers to write or overwrite records and can use onExport() followed by download() to retrieve the complete dataset exposed by the export model. Controllers without granular permission keys are unaffected because userHasAccess() is intentionally default-permissive. This issue is fixed in version 1.2.14.

Impact

Affected versions of Winter CMS allow a backend AJAX handler to be invoked by a plain top-level GET navigation with no CSRF token. Backend\Classes\Controller::actionExists() accepted any public method on a controller as a page action, so handler-shaped names were never reserved from URL dispatch: an authenticated and authorized request to /backend/system/eventlogs/indexonEmptyLog reached the handler of the same name and truncated the system event log. Backend paths are routed through Route::any, and CSRF validation is skipped for HEAD, GET and OPTIONS requests.

The default SameSite=Lax session cookie is sent on top-level cross-site navigation, so a link on an attacker-controlled page is sufficient — no form, no script and no token. Handler arguments are taken from URL path segments, so the attacker also chooses the target record. Affected handlers across the backend, cms and system modules cover log truncation, resetting settings to their defaults, altering backend user state, and deleting CMS templates. None of them disclose data to the attacker or write attacker-controlled content, so the impact is destructive and state-changing rather than confidential.

To actively exploit this issue, an attacker would need no account of their own, but would need an authenticated backend user holding the relevant permission to follow an attacker-supplied link. The permissions guarding the affected handlers, system.accesslogs included, are by default assigned only to the built-in Developer role.

Patches

Page-action dispatch is now restricted to all-lowercase method names, which reserves handler-shaped names (onFoo, indexonFoo) from being reached by URL. AJAX dispatch is unchanged: handlers continue to work over POST with the X-WINTER-REQUEST-HANDLER header exactly as before, and need no changes.

IMPORTANT: This fix includes a breaking change to backend action routing. A public controller method used as a page action must now be named in lowercase — comingsoon() rather than comingSoon() — and dashed URLs are normalised to snakecase, so /coming-soon now resolves to comingsoon() instead of comingSoon(). Plugins with a camelCase page action should rename the method and its view file to match; the published URL does not need to change. Core is unaffected, and a survey of the plugin ecosystem found the change affects only a small number of plugins.

This security issue has been fixed in v1.2.14.

Workarounds

If you cannot upgrade, apply https://github.com/wintercms/winter/commit/353b23804dee2acf49fca996c72637040446824f manually.

As an interim mitigation, set 'samesite' => 'strict' in config/session.php. A strict session cookie is not sent on cross-site top-level navigation, which prevents the victim's session accompanying an attacker's link. Review this against any single sign-on or inbound-link flows into your backend first, as it also affects legitimate cross-site entry.

References

Credit to Awwader (@NRAwwad) for reporting the issue.

For more information

If you have any questions or comments about this advisory: - Email us at hello@wintercms.com

Winter CMS is a content management system built on the Laravel PHP framework. Prior to 1.2.14, BrandSetting::renderCss() and EditorSetting::renderCss() store raw LESS compiler output with Cache::forever() but apply striptags() only to the value returned on a cache miss. The first render after saving custom CSS appears sanitized while priming an unsafe cache entry, and later cache hits return unsanitized output into the backend style element, allowing a user with backend.managebranding or backend.manageeditor to cause stored cross-site scripting when another backend page renders the styles. The styles also appear on unauthenticated backend sign-in, password restore, and password reset layouts. This issue is fixed in version 1.2.14.

Impact

Affected versions of Winter CMS render the search query parameter without HTML encoding inside a <script type="text/template"> block in the backend Table widget partial (modules/backend/widgets/table/partials/table.php):

php value="<?= get('search') ?>"

<script> is an HTML raw-text context, so the surrounding value="…" attribute quoting is not a parser boundary. A literal </script> in the query string terminates the template element early, and everything after it is parsed as ordinary markup in the backend document.

Any backend page rendering a Table or DataTable widget is a sink. The value is read from the global request through the get() helper, which — unlike post() — is not restricted by HTTP method, so a plain top-level GET navigation is sufficient. The template is also emitted unconditionally by the partial, so widgets using the default searching: false configuration are equally affected.

In Winter core the reachable route is the Editor Settings form (/backend/system/settings/update/winter/backend/editor), which renders six datatable fields and is gated by backend.manageeditor — assigned by default to the built-in Developer role. Third-party plugins using the datatable form widget, or the Table widget directly, expose the same sink on their own pages.

An attacker who induces a signed-in backend user to follow a crafted link executes script in that user's authenticated backend origin. The injected script can read the CSRF token published in the backend layout's <meta name="csrf-token"> element and issue credentialed requests as the victim, bounded only by that user's permissions. Because the core sink requires backend.manageeditor, the practical victim is a Developer-role user or superuser — who can edit CMS templates, so script running in that session can chain to server-side code execution.

This is not a permission bypass: the victim must already be authorised for the page, and the attacker gains no permission the victim does not hold.

To actively exploit this issue, an attacker needs no account of their own, but does need an authenticated backend user with access to a page rendering a Table or DataTable widget to follow an attacker-supplied link.

Patches

The search value is now HTML-encoded on output, matching every other value rendered by the same partial and the equivalent handling in the backend Search widget (modules/backend/widgets/search/partials/search.php):

php value="<?= e(get('search')); ?>"

This removes the raw-text terminator: the browser can no longer encounter an attacker-supplied literal </script> while tokenising the document. The template is subsequently parsed once by jQuery when the toolbar is built, so an encoded payload resolves to an inert attribute string rather than markup.

Regression coverage was added in modules/backend/tests/widgets/TableSearchEscapingTest.php, covering plain, mixed-case (</ScRiPt>) and whitespace-bearing (</script >) terminators, both searching states, and preservation of ordinary and Unicode search text.

This security issue has been fixed in v1.2.14.

Workarounds

If you cannot upgrade, apply https://github.com/wintercms/winter/commit/1b6397654124fb44a6abf6f3782b6a1d746cef14 manually — in modules/backend/widgets/table/partials/table.php, change:

php value="<?= get('search') ?>"

to:

php value="<?= e(get('search')); ?>"

A restrictive Content Security Policy served at the web server or reverse proxy can reduce practical exploitability, but it is not a substitute for the fix: Winter's backend ships inline scripts, so a policy permissive enough to run the backend may still permit an injected execution primitive.

References

Credit to Awwader (@NRAwwad) for reporting the issue.

For more information

If you have any questions or comments about this advisory: - Email us at hello@wintercms.com

Impact

Backend\Controllers\MyAccount, introduced in v1.2.13, declares an empty $requiredPermissions array so that any authenticated backend user can manage their own account. It implements the FormController behavior, which exposes three routable actions — create, update and preview — that each take a record id from the URL.

index() passes the authenticated user's own id to the behavior, but the inherited actions were left routable and formFindModelObject() was not scoped, so a caller-supplied id resolved against an unscoped Backend\Models\User query:

GET /backend/backend/myaccount/preview/{otheruserid}

preview disclosed the target user's first name, last name, login, email address and avatar; update was equally routable and additionally disclosed role, group membership, superuser flag and throttle state. Password controls render a mask, so no credential material was exposed. Backend user ids are sequential and trivially enumerated, and as these are GET actions no CSRF token is involved.

The behavior's AJAX handlers (createonSave, updateonSave, updateonDelete) were also dispatchable on these routes, but cross-user writes were blocked by the Backend\Models\User authorization guards added in v1.2.13. The confirmed impact is unauthorized disclosure of backend user profile data.

To actively exploit this security issue, an attacker would need access to the Backend with a user account with any level of access.

Patches

MyAccount no longer exposes the generic record actions it never used as routes, and its form lookup is now pinned to the authenticated user:

- protected $guarded = ['create', 'update', 'preview']; removes the inherited actions from routing. The guard has to be at the routing layer, as handler dispatch ({action}{handler}) runs before the page action. - formExtendQuery() constrains every lookup made by the behavior to the current user's key.

This security issue has been fixed as of v1.2.14 (commit cdbc8f5a23db27f72ccec658a8e5769e6d9f6dcb).

Workarounds

There is no supported workaround other than upgrading. If you cannot upgrade immediately, you may apply the fix manually in modules/backend/controllers/MyAccount.php:

1. Add protected $guarded = ['create', 'update', 'preview']; to the controller. 2. Add a formExtendQuery() method that scopes the lookup to the current user:

php public function formExtendQuery(\Winter\Storm\Database\Builder $query): void { $query->whereKey($this->user->getKey()); }

References

- https://github.com/wintercms/winter/security/advisories/GHSA-j5jq-cr68-v2xx - https://github.com/wintercms/winter/commit/cdbc8f5a23db27f72ccec658a8e5769e6d9f6dcb

Credit to Awwader (@NRAwwad) for reporting the issue.

For more information

If you have any questions or comments about this advisory: - Email us at hello@wintercms.com

Impact

Backend\Widgets\Lists::evalImageTypeValue() interpolated the resolved image URL into a single-quoted src attribute without escaping it. Where a list column of type image rendered an attacker-influenced value, that value could break out of the attribute and inject arbitrary attributes — including event handlers — into the backend list, executing in the session of whichever backend user viewed it.

Winter core ships no image list column, so a default installation is unaffected. Exploitation requires a plugin that renders attacker-influenced values through one.

The supported image sources are plugins, themes, the Media Library, the uploads directory, and Attach\File models; an arbitrary external URL is not among them. ImageResizer::filterGetUrl() returns the value it was given when it cannot resolve an image, however, so an unsupported value reached the attribute verbatim rather than being rejected.

As with previous issues of this kind the severity is limited: an attacker must already be able to store the value, and a backend user must then open the affected list. Note that validating a stored URL was not necessarily sufficient — a payload can survive filtervar($url, FILTERVALIDATEURL), since / is valid both in a URL path and after a quoted HTML attribute value.

Patches

evalImageTypeValue() now escapes the image URL, along with the width and height taken from the column configuration, before interpolating them into the tag.

This security issue has been fixed as of v1.2.14 (commit 0941c9816181095fe35d58e78e6d0c4a49238967).

Workarounds

Apply the commit above to modules/backend/widgets/Lists.php manually if you are unable to upgrade to v1.2.14.

References

- https://github.com/wintercms/winter/security/advisories/GHSA-43w4-4j3c-jx29 - https://github.com/wintercms/winter/commit/0941c9816181095fe35d58e78e6d0c4a49238967

Credit to Seungyeon Park (@sy460129) for reporting the issue.

For more information

If you have any questions or comments about this advisory: - Email us at hello@wintercms.com