EUVD-2026-25370
GHSA-w942-j9r6-hr6r
Severity by source
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/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
Low-privilege authenticated access required via REST API; impact is solely limited integrity (unauthorized content publishing) with no confidentiality or availability effect and no scope change.
Primary rating from GitHub Advisory.
CVSS VectorGitHub Advisory
Lifecycle Timeline
6DescriptionGitHub Advisory
TL;DR
This vulnerability affects all Kirby sites where users have the permission to create pages (pages.create permission is enabled) but not the permission to change the status of pages (pages.changeStatus permission is disabled). This can be due to configuration in the user blueprint(s), via options in the page blueprint(s) or via a combination of both settings.
Users' Kirby sites are *not* affected if their use case does not consider the creation of published pages a malicious action. The vulnerability can only be exploited by authenticated users.
----
Introduction
An authorization bypass allows authenticated users to perform actions they should not be allowed to perform based on their configured permissions, thereby causing a privilege escalation.
The effects of an authorization bypass can include unauthorized access to sensitive information as well as unauthorized changes to content or system information.
Impact
Kirby's user permissions control which user role is allowed to perform specific actions to 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.
For pages, Kirby provides the pages.create and pages.changeStatus permissions (among others). In affected releases, Kirby checked these permissions independently and only for the respective action. However the changeStatus permission didn't take effect on page creation.
New pages are created as drafts by default and need to be published by changing the page status of an existing page draft. This is ensured when the page is created via the Kirby Panel. However the REST API allows to override the isDraft flag when creating a new page. This allowed authenticated attackers with the pages.create permission to immediately create published pages, bypassing the normal editorial workflow.
Patches
The problem has been patched in Kirby 4.9.0 and Kirby 5.4.0. Please update to one of these or a later version to fix the vulnerability.
In all of the mentioned releases, Kirby has added a check to the page creation rules that ensures that users without the pages.changeStatus permission cannot create published pages, only page drafts.
Credits
Kirby thanks @offset for responsibly reporting the identified issue.
AnalysisAI
Kirby CMS's REST API allows authenticated users with the pages.create permission to immediately publish pages by overriding the isDraft flag, bypassing the separate pages.changeStatus authorization check. This affects all 4.x releases before 4.9.0 and 5.x releases from 5.0.0 through 5.3.x, and is exploitable only by authenticated users in deployments where the two permissions are intentionally split. No public exploit code has been identified and EPSS sits at 0.03% (9th percentile), consistent with the SSVC assessment of no known active exploitation; the vulnerability is nevertheless a real workflow integrity bypass for editorial CMS environments.
Technical ContextAI
Kirby is a flat-file CMS distributed as the Composer package getkirby/cms. Its authorization model uses role-based user blueprints (site/blueprints/users/...) and per-model page blueprints (site/blueprints/pages/...) to define granular permissions including pages.create and pages.changeStatus. The root cause is CWE-863 (Incorrect Authorization): the page creation handler in Kirby's REST API evaluated the two permission gates independently rather than compositely. Because the Panel enforces the draft-first workflow at the UI layer, the isDraft parameter bypass was only reachable via direct API calls. Affected packages are pkg:composer/getkirby_cms versions < 4.9.0 and versions >= 5.0.0 < 5.4.0, as confirmed by EUVD-2026-25370 and the GitHub security advisory GHSA-w942-j9r6-hr6r.
RemediationAI
Upgrade to Kirby 4.9.0 (a dedicated security backport for the 4.x branch) or Kirby 5.4.0 (or any later release); both versions add a composite check to the page creation logic that prevents users without pages.changeStatus from creating published pages directly. Downloads and release notes are available at https://github.com/getkirby/kirby/releases/tag/4.9.0 and https://github.com/getkirby/kirby/releases/tag/5.4.0. The vendor explicitly recommends migrating to Kirby 5 where an upgrade is feasible. If immediate patching is not possible, a targeted compensating control is to restrict external access to the Kirby REST API at the web server or firewall level (e.g., block or require additional authentication on the /api/ path); the trade-off is loss of headless or programmatic API integrations. Alternatively, administrators can audit all user blueprints to ensure no role grants pages.create without also granting pages.changeStatus, which eliminates the vulnerable permission configuration without code changes but requires ongoing enforcement as roles are added.
Same weakness CWE-863 – Incorrect Authorization
View allSame technique Authentication Bypass
View allShare
External POC / Exploit Code
Leaving vuln.today