GHSA-mpmw-f6h6-3g26: Insecure Direct Object Reference in Winter CMS My Account Controller

In version 1.2.13 of Winter CMS, developers introduced a dedicated backend controller Backend\Controllers\MyAccount inside the winter/wn-backend-module package. This addition aimed to isolate profile management functionalities for backend users, addressing a previous privilege escalation risk (GHSA-j5jq-cr68-v2xx) in the core Users controller.

To ensure all backend users could adjust their own account settings without needing high-level administrative permissions, the controller set its $requiredPermissions property to an empty array. This configuration opened the controller to any authenticated session on the backend.

However, because the controller implemented the platform's standard FormController behavior, it implicitly inherited routing capabilities for multiple CRUD actions. This inheritance exposed a significant attack surface to low-privilege backend accounts.

The core vulnerability lies in the interaction between the MyAccount controller and the FormController behavior. This behavior dynamically registers endpoints such as /create, /update/{id}, and /preview/{id} to facilitate model operations.

Because these routes take an identifier variable straight from the request URI, they feed the parameter directly into the model lookup logic. In the default configuration, the underlying FormController relies on the formFindModelObject() method, which performs a lookup against the unmodified database query of the associated model, Backend\Models\User.

No scoping mechanism was implemented in the initial release of MyAccount to limit query execution to the active user's session identifier. Consequently, any low-privilege authenticated user could execute direct object queries against any arbitrary database record key simply by incrementing the identifier in the URI.

To fully understand the flaw, we must analyze the code structure before and after the remediation applied in version 1.2.14.

In the vulnerable implementation of MyAccount.php, the controller declared the FormController behavior but lacked any controls to suppress actions or scope queries:

class MyAccount extends Controller
{
    public $implement = [
        \Backend\Behaviors\FormController::class,
    ];
 
    protected $requiredPermissions = [];
}

The patch introduced in commit cdbc8f5a23db27f72ccec658a8e5769e6d9f6dcb establishes a defense-in-depth architecture. It implements a routing-level restriction and a query-level security policy:

// modules/backend/controllers/MyAccount.php
class MyAccount extends Controller
{
    public $implement = [
        \Backend\Behaviors\FormController::class,
    ];
 
    // Guard the default CRUD actions to prevent routing exposure
    protected $guarded = ['create', 'update', 'preview'];
 
    protected $requiredPermissions = [];
 
    // Restrict all FormController query operations to the active session key
    public function formExtendQuery(Builder $query): void
    {
        $query->whereKey($this->user->getKey());
    }
}

By adding the $guarded array, the system instructs the controller's dispatcher to decline external requests targeting these actions. Additionally, overriding formExtendQuery guarantees that even if a routing bypass occurs, the database query restricts output to the current active user's primary key.

Exploiting this vulnerability requires an attacker to possess valid credentials for any backend role, regardless of its permission level. Upon authenticating and obtaining a valid session cookie, the attacker can leverage standard browser tools or HTTP clients to send targeted requests.

Because the underlying vulnerability belongs to the Insecure Direct Object Reference (IDOR) class, exploitation consists of sequentially scanning the ID parameter in the URL. A typical attack lifecycle is illustrated below:

The following HTTP transaction demonstrates how an attacker retrieves private profile details belonging to the administrator account (ID 1) while authenticated as a low-privilege user:

GET /backend/backend/myaccount/preview/1 HTTP/1.1
Host: target-wintercms.local
Cookie: winter_session=eyJpdiI6Ik...
Connection: close

The response contains sensitive data fields rendered within the administration form structure:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
 
<input type='text' name='User[login]' value='admin_root' readonly />
<input type='email' name='User[email]' value='security_admin@company.corp' readonly />
<input type='text' name='User[first_name]' value='Super' readonly />
<input type='text' name='User[last_name]' value='Administrator' readonly />

A notable aspect of the patch for GHSA-mpmw-f6h6-3g26 is the inclusion of dedicated integration tests. The maintainers added MyAccountSecurityTest.php to verify that routing restrictions and model lookups function correctly under adversarial conditions.

The test suite validates that record-scoped actions are strictly non-routable via the controller's action mechanism:

public function testRecordScopedActionsAreNotRoutable(): void
{
    $controller = new MyAccount;
    foreach (['create', 'update', 'preview'] as $action) {
        $this->assertTrue($controller->methodExists($action));
        $this->assertFalse($controller->actionExists($action));
    }
}

Additionally, the test suite verifies that attempts to request another user's record using the internal form-finding routines will fail and throw an ApplicationException:

public function testTheFormLookupIsPinnedToTheCurrentUser(): void
{
    $controller = new MyAccount;
    $this->assertEquals(
        $this->mallory->getKey(),
        $controller->formFindModelObject($this->mallory->getKey())->getKey()
    );
    $this->expectException(ApplicationException::class);
    $controller->formFindModelObject($this->alice->getKey());
}

The security impact of this vulnerability is classified as Medium, receiving a CVSS v3.1 score of 4.3. The primary compromise occurs at the confidentiality level, as unauthorized backend users can harvest sensitive configuration and contact details belonging to administrative accounts.

The exposed data includes login names, email addresses, assigned security roles, group memberships, and superuser flags. In complex enterprise deployments, exposing these fields assists attackers in conducting targeted social engineering, credential stuffing, or spear-phishing campaigns against administrators.

Importantly, integrity and availability remain unaffected. While the default AJAX write-handlers like update_onSave were technically reachable, pre-existing model-level authorization guards added in version 1.2.13 successfully blocked cross-user database writes, preventing attackers from altering administrative records.