Description

Grav CMS 2.0.14 through 2.0.24 contains a privilege escalation vulnerability in the group and account blueprints. The access map is gated by a `security@: admin.super` guard that is resolved by the field's exact path, so a submitted flat dot-notation key such as `access.admin.super` (instead of the nested `access[admin][super]`) matches no blueprint rule, survives BlueprintSchema::filterArray() and flattening, and is written by FlexObject::update() via setNestedProperty(), which splits on `.` and reconstructs the nested value. An authenticated backend operator using the flex accounts backend who holds admin.users but not admin.super can therefore grant admin.super to their own account or to a group they belong to and escalate to full super-admin, gaining control over configuration, plugin and theme installation, the file manager, and all accounts. Fixed in 2.0.25, which drops any dotted key whose ancestor path is disabled or marked validate.ignore.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "8.8",
  "pubDate": "2026-09-26T14:16:50.583Z",
  "pubdate": "2026-09-26T14:16:50.583Z",
  "executiveSummary": "Grav CMS versions 2.0.14 through 2.0.24 are susceptible to a privilege escalation vulnerability within the group and account blueprints.\nThe vulnerability originates from a flaw in how the application handles submitted flat dot-notation keys during the processing of blueprint rules.\nAn authenticated backend operator possessing 'admin.users' permissions, but lacking 'admin.super' privileges, can exploit this flaw to grant themselves or their associated groups elevated 'admin.super' status.\nSuccessful exploitation allows an attacker to bypass security guards designed to protect sensitive access map fields, effectively escalating their privileges to a full super-admin account.\nThis grants the attacker comprehensive control over the CMS, including system configuration, plugin and theme installation, the integrated file manager, and management of all user accounts.\nThe vulnerability is classified as a privilege escalation issue, enabling unauthorized access to administrative functions by exploiting inconsistencies in data filtering and nested property reconstruction.",
  "technicalDetails": "The root cause of this vulnerability lies in the improper handling of field paths within 'BlueprintSchema::filterArray()' and the subsequent write process in 'FlexObject::update()'.\nSecurity checks for the access map are gated by a 'security@: admin.super' directive, which relies on the specific nested structure of the configuration path. The system expects nested data structures, such as 'access[admin][super]', to be passed to the blueprint validation logic.\nWhen a user submits a flat dot-notation key, such as 'access.admin.super', it fails to match the required nested blueprint rules because the schema validation logic does not explicitly account for these flattened strings. Consequently, the input is not dropped or blocked by 'BlueprintSchema::filterArray()'.\nDuring the persistence phase, 'FlexObject::update()' utilizes 'setNestedProperty()', which is designed to interpret dots as separators for nested keys. This function splits the string 'access.admin.super' and reconstructs it into the actual nested array structure ('access' => ['admin' => ['super' => true]]).\nBecause the validation check has already been bypassed due to the initial mismatch of the flat key against the security guard, the reconstructed malicious payload is written directly to the user or group profile.\nAttackers with existing 'admin.users' privileges can leverage this behavior by crafting a POST request containing the flat-notation key. The application processes the update, effectively ignoring the 'security@: admin.super' restriction.\nThe impact is a full administrative account takeover. Once the 'admin.super' bit is set, the attacker gains unrestricted access to the administrative backend. This enables the installation of malicious plugins or themes, which can lead to remote code execution (RCE) on the underlying server, modification of sensitive system files, and complete compromise of all stored user accounts.\nThis vulnerability affects Grav CMS versions 2.0.14 up to 2.0.24. Authentication is required to exploit the backend, and the attacker must possess the 'admin.users' permission level to access the accounts backend where this flaw manifests."
}