EUVD-2026-25370
GHSA-w942-j9r6-hr6r
Attack ChainAIDerived
Hypothetical attack flow derived from CVE metadata – not a confirmed exploit chain
-
AccessAuthenticate with low-privilege CMS editor account
-
DeliveryIdentify pages.create permission is granted but pages.changeStatus is denied
-
ExploitCraft REST API page creation request with isDraft=false
-
ExecutionKirby evaluates only pages.create gate, skips changeStatus check
-
ImpactPage published immediately, bypassing editorial workflow
Vulnerability Assessment
| Weakness |
CWE
OWASP Top 10:2025
A01:2025 - Broken Access Control
ASVS 5.0
V8 - Authorization Authorization logic validation
MITRE ATT&CK
1 technique across 1 tactic: Privilege Escalation The technique list with ATT&CK links and the kill-chain view is part of the Basic plan and up. |
| Exploitation Conditions | Exploitation requires an authenticated user session holding the |
| Impact | The CVSS 4.0 score of 5.3 (Medium) assigns AV:N/AC:L/AT:N/PR:L/UI:N with VI:L and no confidentiality or availability impact, which accurately reflects the attack surface and constrained impact. EPSS at 0.03% (9th percentile) is very low, and the SSVC framework independently rates exploitation as 'none,' automatable as 'no,' and technical impact as 'partial' - all three signals converge on a below-average exploitation risk profile despite the network-accessible vector. The SSVC 'Automatable: no' finding is particularly meaningful: successful exploitation requires deliberate targeting of a site that has specifically split |
| Exploit ScenarioDerived | An authenticated editor-role CMS user who has been granted |
Get an e-mail when this CVE is exploited, patched or re-scored. Free account.
Alert meAnalysisAIv1 – Jul 24, 2026
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.
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.
Affected VersionsENISA
Affected Packages
Source: OSV (Open Source Vulnerabilities)
Affects your stack
Affects 2 packages in composer, euvd
Checking this CVE against your own stacks and servers is part of the Basic plan and up.
Technical ContextAI · show details
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.
Know when the next one hits your stack
- Watch products and get an email when something new is published
- Check this CVE against your own stack and servers
- Exploit and PoC references, threat intelligence from 22 sources
No credit card · 7-day full trial
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
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 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 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.
Threat Intelligence Overview
NVD
CVE.org
EPSS
Vulnrichment
VulDB
How this decision was reached
The engine reads each signal below and applies a fixed list of rules from top to bottom. The first rule that matches sets the recommended action – like a statement, every line is shown.
What every action level means
SSVC AssessmentENISA
Priority Score
Attack Technique
Authentication bypass attacks exploit flaws in the verification mechanisms that control access to systems and applications.
Privilege escalation occurs when an attacker leverages flaws in access control mechanisms to gain permissions beyond what they were originally granted.
Exploit-DB