The vulnerability is a combination of two issues. First, in modules/backend/classes/Controller.php, the run() method did not validate the _handler field from POST requests, unlike the X_WINTER_REQUEST_HANDLER header used in AJAX requests. This allowed an attacker to specify any public, protected, or private method of a controller as a handler.\n\nSecond, the Users controller in modules/backend/controllers/Users.php had a flaw in its constructor. When the requested action was myaccount, it would set its $requiredPermissions to null, effectively disabling all permission checks for that request. \n\nAn attacker could exploit this by first making a request to the myaccount action on the Users controller. Then, by including a crafted _handler field in the POST data (e.g., _handler=update_onDelete), they could execute dangerous methods like update_onDelete, update_onRestore, update_onUnsuspendUser, and update_onManualPasswordReset on arbitrary users. This bypassed the intended backend.manage_users permission, allowing any authenticated backend user to perform administrative actions on other user accounts.\n\nThe patch addresses these issues by: \n1. Adding validation for the _handler field in the base Controller class to ensure it follows the safe on[A-Z][\\w+]* pattern.\n2. Removing the myaccount functionality from the Users controller and moving it to a new, dedicated MyAccount controller that does not have other user management methods, thus eliminating the permission bypass.\n3. Adding defense-in-depth checks at the model level (Backend\\Models\\User) to enforce authorization before performing sensitive operations like deleting, restoring, or unsuspending users.