EUVD-2026-42667
GHSA-23q2-54qv-rq5x
Severity by source
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X
Requires authenticated Panel access (PR:L) and a non-default role configuration disabling pages.access (AC:H); impact is read-only title disclosure only (C:L, I:N, A:N).
Primary rating from Vendor (https://github.com/getkirby/kirby).
CVSS VectorVendor: https://github.com/getkirby/kirby
Lifecycle Timeline
3DescriptionCVE.org
TL;DR
This vulnerability affects all Kirby sites that use the pages field and where users of a particular role have no permission to access pages (pages.access permission is disabled). This can be due to configuration in the user blueprint(s), options in the model blueprint(s), or a combination of both settings.
It was possible to confirm the existence of arbitrary pages and to retrieve the value of the title field of the pages found.
The vulnerability can only be exploited by authenticated users. Write actions are *not* affected by this vulnerability.
----
Introduction
Missing authorization allows authenticated users to perform actions they are not intended to have access to.
The effects of missing authorization can include unauthorized access to sensitive information as well as unauthorized changes to content or system information.
Affected components
Kirby's user permissions control which user role is allowed to perform specific actions on content models in the CMS. These permissions are defined for each role in the user blueprint (site/blueprints/users/...). It is also possible to customize the permissions for each target model in the model blueprints (such as in site/blueprints/pages/...) using the options feature. The permissions and options together control the authorization of user actions.
Kirby provides the pages.access and pages.list permissions (among others). The list permission controls whether affected models appear in lists throughout the Panel and REST API. The access permission has the same effect but also disables direct access to the affected models.
This vulnerability affects the backend logic for the page picker that is used in the pages field to select pages. The picker is opened based on a user-provided parent page or the site model.
Impact
In affected releases, the backend logic did not validate that the user-provided parent page or site was accessible to the current user. This allowed authenticated attackers with knowledge of the full path to an existing page to confirm the existence of a particular page and to retrieve the value of the title field of that page. This could lead to the disclosure of sensitive information.
Patches
The problem has been patched in Kirby 4.9.4 and Kirby 5.4.4. Please update to one of these or a later version to fix the vulnerability.
In all of the mentioned releases, we have added a check verifying that the requested parent page or site is accessible to the current user before returning the picker data.
AnalysisAI
Missing authorization in Kirby CMS's page picker backend exposes restricted page metadata to authenticated users whose roles have pages.access disabled. Affected sites running Kirby up to 4.9.3 or between 5.0.0-alpha.1 and 5.4.3 allow such users to confirm the existence of arbitrary pages and read their title fields by supplying a known page path directly to the picker endpoint - bypassing role-based access controls. No public exploit or active exploitation has been identified; impact is strictly information disclosure with no write capability.
Technical ContextAI
Kirby CMS is a PHP flat-file CMS distributed via Composer as getkirby/cms. Its permission model uses role blueprints (site/blueprints/users/) and per-model options blocks (site/blueprints/pages/) to define named permissions including pages.access and pages.list. The pages.access permission, when disabled for a role, is meant to prevent both listing and direct access to the affected page models. CWE-862 (Missing Authorization) applies here: the server-side handler for the Panel's page picker widget - used when populating a pages field - accepted a user-supplied parent page path and returned picker data without first checking whether the requesting user held the pages.access permission for that parent. The authorization boundary enforced by blueprint configuration was therefore bypassable through a direct API call to the picker endpoint, as the backend skipped the access check entirely for the picker code path.
RemediationAI
Update to Kirby 4.9.4 (https://github.com/getkirby/kirby/releases/tag/4.9.4) or Kirby 5.4.4 (https://github.com/getkirby/kirby/releases/tag/5.4.4), or any subsequent release. Both versions introduce an authorization check in the page picker backend that validates the requesting user holds pages.access for the supplied parent page before returning picker data. The vendor recommends upgrading to Kirby 5 where operationally feasible; 4.9.4 is an explicit security backport for sites unable to migrate immediately. If an emergency patch cannot be deployed, the most targeted compensating control is to revoke Panel access entirely for roles configured with pages.access restrictions - this eliminates the attack surface but removes those users' Panel functionality. Narrower workarounds such as disabling the pages field in blueprints used by restricted roles would also block exploitation while preserving other Panel access, at the cost of losing page-selection functionality for those roles.
Same weakness CWE-862 – Missing Authorization
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today