CVE-2026-40099: Incorrect Authorization Bypass in Kirby CMS Page Creation

Kirby CMS implements a role-based access control system to govern content modifications. This system relies on granular permissions defined in user and model blueprints. Permissions such as pages.create and pages.changeStatus control the lifecycle of content objects within the CMS.

The vulnerability identified as CVE-2026-40099 exposes a flaw in how the system enforces these permissions during page instantiation. The core issue lies in the decoupled nature of creation and status management operations. While the web-based Panel UI enforces a strict sequence of actions, the REST API interface allows clients to specify the initial state of a new page object.

Authenticated actors with basic creation privileges can exploit this inconsistency to alter the status of new content. The vulnerability allows actors to bypass the intended editorial workflow. The result is an incorrect authorization condition (CWE-863) where content is immediately published without the necessary pages.changeStatus authorization.

The root cause of this vulnerability is an incomplete authorization boundary within the REST API page creation controller. Kirby handles content states through a boolean isDraft flag attached to page objects. When a user creates a page via the administrative panel, the frontend explicitly creates the object as a draft.

Publishing a draft requires a subsequent request that specifically triggers the changeStatus action. The backend validates the pages.changeStatus permission during this secondary request. However, the REST API permits clients to supply the isDraft property within the initial POST payload used for page creation.

The PageRules::create method validates the user's pages.create permission but previously failed to evaluate the isDraft flag. Because the method did not verify the final state of the object, the system instantiated the page directly into a published state. This architectural oversight allowed the pages.create permission to implicitly grant pages.changeStatus capabilities during the exact moment of object creation.

The official patch addresses the authorization bypass by enforcing state validation within the creation lifecycle. The critical fix resides in src/Cms/PageRules.php, specifically within the create method. The developers added a conditional block to evaluate the requested state of the incoming page object.

If the incoming object specifies a non-draft state, the code explicitly delegates authorization to the publish ruleset.

// File: src/Cms/PageRules.php
public static function create(Page $page): void
{
    // ... existing validation logic ...
 
    // NEW: creating a non-draft bypasses the normal publish flow;
    // enforce the same rules
    if ($page->isDraft() === false) {
        self::publish($page);
    }
 
    // ... rest of validation ...
}

By invoking self::publish($page), the method ensures the current user possesses the required pages.changeStatus permission before proceeding. If the user lacks this permission, the framework throws a PermissionException and aborts the creation process.

Additional hardening commits accompany this primary fix. Commit bd55bab90bb800c2ab3c71f37bd74981c646acea unsets the blueprint key during property normalization. This prevents actors from passing custom blueprint definitions via the API, effectively blocking secondary authorization bypasses through model definition manipulation.

The following flowchart maps the patched execution path during a REST API page creation request.

Exploitation requires an active session with a user account possessing the pages.create permission. The attacker must obtain valid authentication tokens or session cookies to interact with the Kirby REST API. Network access to the administrative API endpoint is a strict prerequisite for this attack vector.

The attacker constructs a standard HTTP POST request directed at the target collection endpoint. The critical component of the exploit is the JSON payload containing the isDraft: false parameter. The system processes this payload without stripping the state directive.

An example exploit payload targets the API endpoint responsible for content ingestion.

POST /api/pages HTTP/1.1
Host: target-kirby-instance.local
Authorization: Bearer <valid_token>
Content-Type: application/json
 
{
  "parent": "blog",
  "slug": "unauthorized-post",
  "title": "Exploit Test",
  "isDraft": false
}

The server processes the request, evaluates the pages.create permission, and initializes the page. Due to the missing state check in unpatched versions, the system assigns the page a listed status. The content immediately appears on the public-facing application without undergoing the mandatory editorial review process.

The successful exploitation of this vulnerability compromises the integrity of the content management workflow. Attackers with low-level authoring privileges can bypass editorial restrictions designed to gate content publication. The impact is isolated to application data integrity and does not extend to the underlying host operating system.

The CVSS v4.0 vector (CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N) accurately reflects the technical scope. The attack requires low privileges and operates over the network with low complexity. The consequence is a low integrity impact because the attacker can only publish content they are already authorized to draft.

While technical severity is moderate, the business impact varies based on organizational reliance on the CMS workflow. An attacker can publish defacement materials, SEO spam, or unauthorized announcements directly to the live environment. The lack of required user interaction means the exploit can be fully automated across multiple compromised editor accounts.

The vendor addresses this vulnerability in Kirby versions 4.9.0 and 5.4.0. Administrators must update the application core to implement the required PageRules validation checks. The update process applies the updated authorization boundary to both the REST API and internal model logic.

Organizations unable to deploy the patch immediately can mitigate the risk through role configuration modifications. Administrators should review all user blueprints within site/blueprints/users/ and identify roles possessing the pages.create permission. Removing this permission temporarily prevents actors from initiating the flawed creation sequence.

Alternatively, administrators can align permissions so that only highly trusted users hold the pages.create role. Ensuring that all users with creation privileges also hold pages.changeStatus privileges eliminates the risk of an authorization escalation. These workarounds require careful testing to avoid disrupting legitimate business operations.

Post-remediation actions include auditing the application environment for unauthorized published content. Security engineers should examine web server access logs for POST requests to /api/pages exhibiting an unexpected correlation with user roles lacking publication authority. Identifying such anomalies confirms historical exploitation of the flaw.