GHSA-j5jq-cr68-v2xx: CSRF

Published Aug 12, 2026
·
Updated

Impact

Affected versions of Winter CMS did not validate the handler name submitted through the form postback mechanism (handler POST field) in the same way as AJAX requests (XWINTERREQUESTHANDLER header). The AJAX path validates that handler names match the on[A-Z][\w+] pattern, but the postback path passed the handler name directly to the handler dispatcher with no validation.

This allowed an authenticated backend user to call any method on a controller — including action-prefixed, protected, and private methods — by submitting a crafted POST request with a handler field, as long as the controller either:

- Contains a publicly available action via the $publicActions property, or - Degrades or removes the $requiredPermissions check in its constructor based on a condition

The backend's own Users controller was affected by the second scenario: it set $requiredPermissions to null for the myaccount action, allowing any authenticated backend user to access the controller without the backend.manageusers permission. Combined with the postback bypass, this allowed calling controller methods such as updateonDelete, updateonRestore, updateonUnsuspendUser, and updateonManualPasswordReset with attacker-controlled parameters.

Note that CSRF tokens are still verified on all POST requests, so the attacker must be logged into the backend with a valid session.

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

The Winter CMS maintainers strongly recommend that all Winter CMS sites that have any reliance on the roles & permissions system to update immediately. Security fixes have been backported to all major versions of Winter (1.0, 1.1, and 1.2).

Patches

The postback handler path now validates handler names using the same rules as the AJAX path. The My Account functionality has been moved to a dedicated controller that does not expose user management methods. Defence in depth has been applied at the model level to prevent unauthorized user record modifications regardless of the entry point.

This security issue has been fixed as of v1.2.13.

Workarounds

If users cannot upgrade, they may apply the following changes to their Winter CMS installation manually to resolve this issue:

1. In modules/backend/classes/Controller.php, validate the handler POST field against the on[A-Z][\w+] pattern before passing it to runAjaxHandler(). 2. In modules/backend/controllers/Users.php, remove the conditional that sets $requiredPermissions to null for the myaccount action.

Affected Software

1 affected componentFixes available
composer/winter/wn-backend-module<=1.2.12
1.2.13

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade composer/winter/wn-backend-module to a version that resolves this vulnerability.

    Fixed in 1.2.13
  2. Upgrade

    Upgrade Winter CMS to a version that resolves this vulnerability.

    Fixed in 1.2.13
  3. Configuration

    In modules/backend/classes/Controller.php, validate the _handler POST field against the on[A-Z][\w+]* pattern before passing it to runAjaxHandler().

    Winter CMS backend modules/backend/classes/Controller.php validate _handler POST field = validate _handler against regex on[A-Z][\w+]* before passing to runAjaxHandler()
  4. Configuration

    In modules/backend/controllers/Users.php, remove the conditional that sets $requiredPermissions to null for the myaccount action (so backend.manage_users permission is still required).

    Winter CMS backend modules/backend/controllers/Users.php $requiredPermissions for myaccount action = do not set $requiredPermissions to null for the myaccount action

Event History

Aug 12, 2026
Advisory Published
via GitHub·03:15 PM
Data Sourced
via GitHub·03:15 PM
DescriptionWeaknessAffected Software
Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of GHSA-j5jq-cr68-v2xx?

The severity of GHSA-j5jq-cr68-v2xx is rated as 65.

2

How do I fix GHSA-j5jq-cr68-v2xx?

To fix GHSA-j5jq-cr68-v2xx, ensure that handler names submitted through the form postback mechanism are validated in accordance with the same standards as AJAX requests.

3

What versions of Winter CMS are affected by GHSA-j5jq-cr68-v2xx?

GHSA-j5jq-cr68-v2xx affects versions of Winter CMS prior to version 1.2.13.

4

What type of vulnerability is GHSA-j5jq-cr68-v2xx?

GHSA-j5jq-cr68-v2xx is classified as a Cross-Site Request Forgery (CSRF) vulnerability.

5

What is the impact of GHSA-j5jq-cr68-v2xx?

The impact of GHSA-j5jq-cr68-v2xx is that it allows potentially unsafe handler names to be submitted without adequate validation.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203