GHSA-rvmm-v933-jgxq: Missing Authorization Check in Craft CMS ChartsController

Craft CMS features an administrative dashboard containing visual metric components designed to provide administrators with quick insights into site usage. The ChartsController class coordinates data retrieval for these components. Under standard operations, charts display metadata such as user registrations, system activity, and asset counts. This data retrieval operates via specified action endpoints, which handle POST requests with structured query parameters.

Historically, user-related actions in Craft CMS are bound by authorization checks. Access to user directories, groups, and growth metrics should be restricted to users possessing the viewUsers permission. However, the endpoint /actions/charts/get-new-users-data did not validate if requests were initiated from within the authorized Control Panel context or by a user with explicit privileges.

The lack of validation exposed a vulnerable attack surface. An attacker with standard authenticated access could query this endpoint directly. The resulting response disclosed time-series registration metrics and user group distribution patterns, circumventing intended security constraints.

The fundamental issue stems from a missing authorization context check inside ChartsController::actionGetNewUsersData(). Craft CMS allows routing to controller actions via specific frontend action parameters or backend Control Panel routes. If a controller action fails to explicitly assert its routing domain, it may remain accessible to frontend actions.

In the vulnerable codebase, actionGetNewUsersData() accepted inbound requests without verifying that they originated from the Control Panel (requireCpRequest()). Consequently, the action was exposed on the public-facing interface to any authenticated user session, bypassing the restrictive access controls defined for the Control Panel directory.

Furthermore, the action failed to enforce the explicit viewUsers permission. In multi-tenant or role-restricted environments, users are often assigned low-privilege roles, such as "Content Editor". These roles are granted base Control Panel access (accessCp) but are restricted from accessing user administration features. The absent permission validation allowed these restricted accounts to directly query the database for registration statistics.

To understand the flaw, we analyze the implementation of actionGetNewUsersData within src/controllers/ChartsController.php. Prior to the security patch, the method immediately extracted request parameters without verifying the origin of the route or the privileges of the active session.

// Vulnerable Code Path
public function actionGetNewUsersData(): Response
{
    // Missing: $this->requireCpRequest() or explicit permission checks
 
    $userGroupId = $this->request->getBodyParam('userGroupId');
    $startDateParam = $this->request->getRequiredBodyParam('startDate');
    $endDateParam = $this->request->getRequiredBodyParam('endDate');
    // ... execution of user query ...
}

The remediation committed in 9ee53efc1314e6aba32771c66a13e072a246f4ce introduced a validation call at the entry point of the controller action. By calling $this->requireCpRequest(), the application now verifies that the request context matches the admin Control Panel.

// Patched Code Path
public function actionGetNewUsersData(): Response
{
    // Verifies the request originates from the Control Panel context
    $this->requireCpRequest();
 
    $userGroupId = $this->request->getBodyParam('userGroupId');
    $startDateParam = $this->request->getRequiredBodyParam('startDate');
    $endDateParam = $this->request->getRequiredBodyParam('endDate');
    // ... execution of user query ...
}

While this patch blocks unauthenticated external requests and frontend-only users, a minor residual gap remains. The call to requireCpRequest() does not validate the specific viewUsers permission. Control Panel users with minimal privileges (accessCp only) can still access the route. If a deployment relies on granular user group isolation, these low-privilege users can query stats about other user groups, though direct PII is not leaked.

Exploitation requires a valid session on the target application. This session can belong to a low-privileged user possessing basic Control Panel privileges. The attacker first authenticates and extracts the active CSRF token (CRAFT_CSRF_TOKEN) from the document object model.

The attacker then constructs a structured HTTP POST request to the action endpoint. The request payload must include valid startDate and endDate parameters, alongside an optional userGroupId parameter. Specifying different IDs allows the attacker to query registration statistics for specific target user groups sequentially.

curl -X POST "https://example.com/actions/charts/get-new-users-data" \
     -H "Content-Type: application/x-www-form-urlencoded" \
     -H "Cookie: CraftSessionId=9ee53efc1314e6aba32771c66a13e0" \
     --data-urlencode "CRAFT_CSRF_TOKEN=abc123xyz" \
     --data-urlencode "startDate=2026-01-01" \
     --data-urlencode "endDate=2026-12-31" \
     --data-urlencode "userGroupId=2"

Upon execution, the server processes the database query and returns a JSON response containing the registration counts grouped chronologically. This response leaks aggregate site metrics. An attacker can use this data to perform reconnaissance, mapping user registration trends and estimating the sizes of internal user groups.

The immediate impact of this vulnerability is unauthorized information disclosure. While the endpoint does not leak high-severity sensitive data like plaintext credentials, password hashes, or full names, it exposes system-wide user growth data. An attacker can determine historical user sign-up patterns and estimate platform adoption rates.

In enterprise and multi-tenant environments, user demographics and registration velocity constitute proprietary business intelligence. For instance, an unauthorized competitor with low-privileged access could map active growth cycles. Additionally, mapping specific user group IDs allows attackers to assess which administrative or standard groups are actively expanding.

The vulnerability represents a failure in depth-of-defense design. It illustrates how standard controller endpoints can accidentally expose sensitive data metrics if authorization checks are only enforced at the UI layer rather than the API layer. Remediation is required to maintain complete data confidentiality across role-based access control policies.

Administrators should immediately deploy updated packages. For installations running the 4.x branch, upgrade to version 4.18.1 or higher. For installations running the 5.x branch, upgrade to version 5.10.3 or higher. These releases implement the necessary request context verification.

If immediate patching is not feasible, restrict route access at the web server layer. WAF rules can block incoming requests to /actions/charts/get-new-users-data or equivalent rewrite patterns if they originate from unauthorized IP ranges or lack admin session cookies. However, patching via Composer remains the recommended path.

To detect previous exploitation attempts, review application logs for POST requests directed to the target action path. Pay particular attention to requests submitted by users who lack administrative rights. Correlating these requests with user group IDs in the query payload helps identify unauthorized intelligence-gathering activities.