CVE-2026-41325: Authorization Bypass via Blueprint Injection in Kirby CMS

Kirby CMS utilizes blueprints to define content structures and enforce user permissions. The application relies on these YAML and PHP configuration files to dictate which roles can perform specific actions, including resource creation. This mechanism forms the core of the CMS's authorization boundary for administrative and editorial tasks.

An incorrect authorization vulnerability exists in the model instantiation logic for pages, files, and users. The application fails to properly sanitize user-supplied properties during the creation flow. This omission permits authenticated actors to supply their own blueprint definitions at runtime via the API.

By defining a custom blueprint within the creation request, the final authorization check evaluates the attacker-supplied configuration rather than the server-defined rules. This architectural flaw nullifies the intended access controls and allows low-privileged users to provision restricted resources.

The root cause is insecure data normalization within the create methods of the Page, File, and User models. When the application receives a request to instantiate a new model, it passes the input payload through the normalizeProps function. This function is responsible for preparing the data array before applying it to the new object instance.

In vulnerable versions, normalizeProps accepts the blueprint key from the user-provided JSON payload without stripping it. The application subsequently uses this attacker-controlled key to populate the object's internal blueprint configuration. This configuration strictly dictates the effective permissions, termed "options," for the newly created resource.

The system performs a final authorization check using the model's derived options. Because the injected blueprint data overrides the default template settings, the system evaluates the attacker's options.create boolean instead of the developer's intended policy. The system inherently trusts the manipulated model state, resulting in a successful security bypass.

The vulnerability resides in the property normalization pipeline prior to model instantiation. The flawed implementation directly maps input keys to model properties without explicitly stripping administrative or internal configuration keys. This allows an external caller to inject values into the $props array that modify the core logic of the resulting object.

The patch introduced to mitigate this vector strictly filters the blueprint key. The modification occurs within the normalizeProps method across src/Cms/FileActions.php, src/Cms/PageActions.php, and src/Cms/UserActions.php.

protected static function normalizeProps(array $props): array
{
    // Prevent injecting blueprint as this always must be derived from
    // the template/model name and blueprint object in the app,
    // never directly be supplied by the caller
    unset($props['blueprint']);
    // ... rest of method
}

By explicitly unsetting the blueprint array key, the application enforces that the blueprint is exclusively derived from the server-side template name and internal blueprint object. This structural change ensures the caller cannot influence the authorization options of the resulting model.

Exploitation requires the attacker to possess authenticated access to the Kirby Panel or API. The specific privilege level is irrelevant as long as the user possesses valid session credentials. The attacker interacts directly with the resource creation API endpoints, such as /api/pages, to trigger the vulnerability.

The attacker constructs a POST request containing a malicious JSON payload. The payload includes standard resource attributes alongside a nested blueprint object. This nested object explicitly sets the create permission to true, overriding any restrictions bound to the targeted template.

{
  "slug": "unauthorized-page",
  "template": "default",
  "blueprint": {
    "options": {
      "create": true
    }
  }
}

The application processes the request, merges the malicious blueprint into the model, and evaluates the create option. The check resolves to true, and the system provisions the requested resource. The attacker successfully bypasses the server-side restrictions and generates content or user accounts they are otherwise prohibited from creating.

The primary impact is a severe integrity violation within the CMS environment. Attackers can provision unauthorized pages, modify content structures, and potentially escalate privileges by creating administrative user accounts. The vulnerability completely undermines the role-based access control mechanisms defined by the site developers.

The CVSS 4.0 vector (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N) yields a base score of 7.1. This reflects the low attack complexity and the complete loss of integrity for the affected resources. The confidentiality and availability metrics remain unaffected in the primary exploitation scenario.

Secondary vulnerabilities addressed alongside this issue amplify the overall risk. The presence of CDATA smuggling and double resolution of queries indicates that authenticated attackers could chain these issues to extract sensitive information. These chained vectors permit the exposure of administrator password hashes and facilitate deeper data enumeration.

The vendor addressed the vulnerability in Kirby CMS releases 4.9.0 and 5.4.0. Organizations operating vulnerable versions must upgrade immediately to restore the integrity of the authorization model. The patches enforce strict property filtering and prevent user-controlled data from influencing internal model states.

Alongside the primary fix, the updates introduce multiple defense-in-depth measures. The PageRules::create method now evaluates changeStatus permissions if a page originates in a non-draft state. Additionally, Options and Option classes default to disabling query resolution, mitigating the related information disclosure flaws.

Standardized API visibility controls are now enforced using .filter('isListable', true). This prevents unauthorized resource enumeration through sibling, child, and parent endpoints. Developers should review their custom blueprint configurations to ensure proper permission definitions remain active post-upgrade.