CVE-2026-86731: Craft CMS 5.0.0-RC1 before 5.10.12 Permission Escalation via UsersController
Craft CMS versions 5.0.0-RC1 through 5.10.11 are missing an admin-target guard in UsersController::actionActivateUser (the users/activate-user action). While the action requires the administrateUsers permission, it does not call requireAdmin() when the targeted user is an administrator, unlike the mirror action actionDeactivateUser. As a result, an authenticated control panel user who is not an administrator but holds the administrateUsers permission can activate a pending or deliberately deactivated administrator account, which can lead to permission escalation when combined with resetting that account's password. The issue is fixed in Craft CMS 5.10.12.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
Craft CMSto a version that resolves this vulnerability.Fixed in 5.10.12 - Configuration
Ensure the action includes an admin-target guard (i.e., equivalent to requireAdmin() behavior) so that activating a targeted administrator account is blocked for non-administrators.
Craft CMS UsersController::actionActivateUser (users/activate-user action) Admin-target guard (requireAdmin) when activating an administrator user = enabled
Event History
Frequently Asked Questions
Which deployments are affected?
Craft CMS versions 5.0.0-RC1 through 5.10.11 are affected. The issue is fixed in Craft CMS 5.10.12.
What access does an attacker need?
An attacker must be authenticated to the Craft control panel as a non-administrator user with the administrateUsers permission. No user interaction is required.
Are administrator accounts directly exposed to any user-management role?
No. The affected action still requires administrateUsers permission. The missing check specifically allows a non-administrator holding that permission to activate a pending or deliberately deactivated administrator account.
How could this result in administrator-level access?
The non-administrator can activate the targeted administrator account through the users/activate-user action. The description states that this can lead to permission escalation when combined with resetting that administrator account's password.
What should be reviewed if immediate patching is not possible?
Review which non-administrator control-panel accounts have the administrateUsers permission, and remove that permission where it is not essential. Review pending or deactivated administrator accounts, since those are the administrator accounts that can be activated through the affected action.