Search for packages
| purl | pkg:composer/getkirby/cms@5.0.0 |
| Next non-vulnerable version | 5.4.1 |
| Latest non-vulnerable version | 6.0.0-alpha.1 |
| Risk | 4.0 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-4wcn-6ujb-tuhr
Aliases: CVE-2026-42137 GHSA-85x2-r8xv-ww8c |
Kirby CMS's `pages.access/list` and `files.access/list` permissions are not consistently checked in the Panel and REST API ### TL;DR This vulnerability affects all Kirby sites where users of a particular role have no permission to access or list pages or files (`pages.access`, `pages.list`, `files.access` or `files.list` permission is disabled). This can be due to configuration in the user blueprint(s), via `options` in the model blueprint(s) or via a combination of both settings. **This vulnerability is of high severity for affected sites.** Consumers' Kirby sites are *not* affected if they intend all users to be able to access all pages and files of the site. 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. ### 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. Kirby provides the `pages.access`, `pages.list`, `files.access` and `files.list` permissions (among others). The `list` permissions control whether affected models appear in lists throughout the Panel and REST API. The `access` permissions have the same effect but also disable direct access to the affected models. In affected releases, Kirby did not consistently hide non-listable models (models for which the respective `access` or `list` permission was disabled) in the following scenarios: - The changes dialog in the Panel listed changed models even if they were not listable. - The REST API respected the permissions during direct model access, but did not consistently filter collections as well as related models that are included in the API responses for convenience. This includes: - missing permission checks for children, drafts, files, parents and siblings of pages, - missing permission checks for parents and siblings (`next`/`nextWithTemplate `, `prev`/`prevWithTemplate`) of files, - missing permission checks for children, drafts and files of the site model, - missing permission checks for files of users, - incorrect permission checks for `pages.access` instead of `pages.list` for the site and pages children and search routes and - incorrect permission checks for `files.access` instead of `files.list` for the account, site, pages and users files and search routes, - The Panel images for site, pages and users were displayed in lists of the parent model even if the image files were not listable. - The link targets for the previous and next files in the files view were not gated by the files being listable. ### Patches The problem has been patched in [Kirby 4.9.0](https://github.com/getkirby/kirby/releases/tag/4.9.0) and [Kirby 5.4.0](https://github.com/getkirby/kirby/releases/tag/5.4.0). Please update to one of these or a [later version](https://github.com/getkirby/kirby/releases) to fix the vulnerability. In all of the mentioned releases, we have added permission checks for `$model->isListable()` in all of the affected places. This ensures that results are filtered by the listable property, thereby enforcing the `pages.access`, `pages.list`, `files.access` and `files.list` permissions consistently. |
Affected by 6 other vulnerabilities. |
|
VCID-6cfu-ugc9-3qgb
Aliases: CVE-2026-44175 GHSA-5fhx-9q32-q257 |
Kirby CMS vulnerable to cross-site scripting (XSS) from list field content in the site frontend ### TL;DR This vulnerability affects all Kirby sites that use the list field or list block, when content is authored by users who may not be fully trusted. The attack requires an authenticated Panel user with update permission to any list field or list block. **This vulnerability is of high severity for affected sites.** Kirby sites are *not* affected if they don't use the list field (or blocks field with the list block) in any of their blueprints, or if every user who can edit content is fully trusted. The attack only surfaces in the site frontend (i.e. in the consuming project's templates). The Panel itself is unaffected and will not execute JavaScript that was injected into list field content. ---- ### Introduction Cross-site scripting (XSS) is a type of vulnerability that allows to execute any kind of JavaScript code inside the site frontend or Panel session of the same or other users. In the Panel, a harmful script can for example trigger requests to Kirby's API with the permissions of the victim. In a *stored* XSS attack, the malicious payload is saved into the content data and has the potential to affect other users or site visitors. Such vulnerabilities are critical if applications might have potential attackers in their group of authenticated Panel users. They can escalate their privileges if they get access to the Panel session of an admin user. Depending on the site, other JavaScript-powered attacks are possible. A specific class of stored XSS is auto-firing, meaning the malicious injected JavaScript code is executed by the browser when the page loads without the victim having to perform a specific action. ### Affected components Kirby's [list field](https://getkirby.com/docs/reference/panel/fields/list) stores its formatted content as HTML code. Unlike with other field types, it is not possible to [escape HTML special characters](https://getkirby.com/docs/guide/templates/escaping) against cross-site scripting (XSS) attacks, otherwise the formatting would be lost. ### Impact In affected releases, Kirby did not securely sanitize the contents of list fields on save. This allowed attackers to inject malicious HTML code into the content file by sending it to Kirby's API directly without using the Panel. This malicious HTML code would then be displayed on the site frontend and executed in the browsers of site visitors and logged in users who are browsing the site. ### Patches The problem has been patched in [Kirby 4.9.1](https://github.com/getkirby/kirby/releases/tag/4.9.1) and [Kirby 5.4.1](https://github.com/getkirby/kirby/releases/tag/5.4.1). Please update to one of these or a [later version](https://github.com/getkirby/kirby/releases) to fix the vulnerability. In all of the mentioned releases, Kirby has added HTML sanitization (like in the writer field) to the backend code that handles updates to the contents of list fields. ### Credits Kirby thanks @offset for responsibly reporting the identified issue. |
Affected by 0 other vulnerabilities. |
|
VCID-7vp6-yf7c-nkcp
Aliases: CVE-2026-21896 GHSA-4j78-4xrm-cr2f |
Kirby is missing permission checks in the content changes API The missing permission checks allowed attackers with Panel access to create or discard a changes version or update the content fields in an existing changes version. All of these actions could affect arbitrary models. This could cause the following impact: - Attackers could maliciously create changes versions for all models of the site, creating editing locks that would prevent other authenticated users from making content changes until those locks were cleared. - Attackers could update the content in a malicious way, for example by adding defamatory or spam content or by including malicious links or scripts. While this updated content would not immediately be published to the site, an inattentive editor with update permissions could inadvertently publish these changes in the belief that an authorized user has made them. - Attackers could discard extensive changes, making editors lose their content work. |
Affected by 8 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-8a1t-g8pv-4fcb
Aliases: CVE-2026-40099 GHSA-w942-j9r6-hr6r |
Kirby's page creation API bypasses the changeStatus permission check via unfiltered isDraft parameter ### 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](https://github.com/getkirby/kirby/releases/tag/4.9.0) and [Kirby 5.4.0](https://github.com/getkirby/kirby/releases/tag/5.4.0). Please update to one of these or a [later version](https://github.com/getkirby/kirby/releases) 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. |
Affected by 6 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-9svs-tvxm-bfe5
Aliases: CVE-2026-44174 GHSA-86rh-h242-j8xp |
Kirby CMS has an Arbitrary Method Call via REST API Search and Collection Query Endpoints ### TL;DR This vulnerability affects all Kirby sites that might have potential attackers in the group of authenticated Panel users. **This vulnerability is of high severity for affected sites and has a high real-world impact.** ---- ### Introduction Arbitrary method call is a type of arbitrary code execution. It is a vulnerability that allows attackers to run any commands or code of the attacker's choice on a target machine or in a target process. Depending on the set of accessible methods, this can lead to disclosure of sensitive information or to unintended and malicious write actions. ### Affected components Kirby's data model is made up of model objects that are contained in collection objects. These collections can be queried with methods such as `$collection->filter()`, `$collection->sort()`, `$collection->group()`, `$collection->pluck()` and `$collection->findBy()`. Each of these methods allows to query the models contained in the collection by any accessible model attribute (field or method). Kirby also provides endpoints in its REST API that allow to search through users or through children and files of the site or of a particular page. These endpoints allow the `search`, `not`, `filter` and `sort` queries as well as options to paginate the result. The same kind of queries can also be provided to API collections such as `/<site|page|user>/blueprints`, `/<site|page>/children`, `/<model>/files`, `/languages`, `/roles`, `/translations`, `/users` and `/<user>/roles`. ### Impact In affected releases, Kirby did not validate the model attributes that were used in the collection queries. This allowed attackers to include arbitrary model methods in their queries. This includes methods with sensitive data such as `password()` (disclosing the password hash) or `root()` (disclosing the absolute filesystem path on the server) as well as methods that perform impactful actions such as `loginPasswordless()` (causing a privilege escalation to another user) or `delete()` (deleting all queried models in one go if the authenticated user has appropriate permissions). ### Patches The problem has been patched in [Kirby 4.9.1](https://github.com/getkirby/kirby/releases/tag/4.9.1) and [Kirby 5.4.1](https://github.com/getkirby/kirby/releases/tag/5.4.1). Please update to one of these or a [later version](https://github.com/getkirby/kirby/releases) to fix the vulnerability. In all of the mentioned releases, Kirby has added a blocklist of sensitive model methods that should not be called during collection operations and limited the query options for the affected endpoints to search and pagination. ### Credits Kirby thanks @mojamojam for responsibly reporting the identified issue. |
Affected by 0 other vulnerabilities. |
|
VCID-akyk-rcp8-t7af
Aliases: CVE-2026-45334 GHSA-39vq-49qm-r2mc |
Kirby CMS's content locks disclose IDs and emails of inaccessible users from `users.access/list` permissions ### TL;DR This vulnerability affects all Kirby sites that restrict the visibility of users for certain roles via the `users.access` or `users.list` permissions. A site is affected if users of a particular role are not allowed to see other users in the Panel, for example because the role's blueprint sets `users.access: false` or `users.list: false` as permission for the authenticated user role and/or as option for the target user role. A Kirby site is *not* affected if all authenticated Panel users are permitted to access and list other users. The vulnerability can only be exploited by authenticated users. --- ### Introduction Missing authorization allows authenticated users to gain access to information they are not intended to see. 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 or access specific information in the CMS. These permissions are defined for each role in the user blueprint (`site/blueprints/users/...`). The `users.access` and `users.list` permissions control whether users of a given role are allowed to access and list other users in the Panel. It is also possible to customize the permissions for each target role using the `options` feature. The permissions and options together control the authorization of user actions. Kirby's Panel includes a content-locking feature that records which user currently has a model open for editing. This lock prevents conflicting edits by multiple users and displays the locking user's identity in the Panel UI so other users know who to contact. Internally, the locking user's email address and identifier are included in every Panel view payload and in error responses returned when a user attempts to edit a model that is currently locked by another user. ### Impact In affected releases, this lock information was returned without checking whether the requesting user had permission to access or list the locking user. This allowed a low-privilege authenticated Panel user, whose role was configured with `users.access: false` or `users.list: false`, to learn the email address and identifier of any user who currently had a model open for editing in the Panel, including administrators and other higher-privilege users. Content locks are active for a configurable window (10 minutes by default). The email address can allow to enumerate admin accounts, target phishing, and feed credential-stuffing attacks against the Kirby installation or other sites. The internal user ID can be cross-referenced with other endpoints once the requester has obtained a higher privilege through unrelated means. ### Patches The problem has been patched in [Kirby 4.9.1](https://github.com/getkirby/kirby/releases/tag/4.9.1) and [Kirby 5.4.1](https://github.com/getkirby/kirby/releases/tag/5.4.1). Please update to one of these or a [later version](https://github.com/getkirby/kirby/releases) to fix the vulnerability. In the mentioned releases, the lock information is now filtered based on the requesting user's permissions. The identity of the locking user is hidden when the requesting user does not have permission to access or list that user. ### Credits Kirby thanks Matteo Panzeri (@matte1782) for responsibly reporting the identified issue. |
Affected by 0 other vulnerabilities. |
|
VCID-e9gx-3frn-gfeu
Aliases: CVE-2026-42051 GHSA-x68m-c7jf-2572 |
Kirby CMS's system API endpoint leaks installed version and license data to authenticated users ### TL;DR This vulnerability affects all Kirby sites that might have potential attackers in the group of authenticated Panel users. ---- ### 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. ### Impact Kirby's user permissions control which user role is allowed to perform specific actions in the CMS. These permissions are defined for each role in the user blueprint (`site/blueprints/users/...`). The permissions control the authorization of user actions (with handling of model-specific authorization omitted here for brevity). Kirby provides the `access.system` permission (among others) that controls access to the system area of the Kirby Panel. This area contains internal system information like the installed Kirby, plugin and server versions, security state and Kirby license. If the `access.system` permission is disabled for a user role, users of that role should not be able to access this internal system information. However it is also possible to access some system information via the `/api/system` REST API endpoint. In affected releases, the response of this endpoint for authenticated users contained the installed Kirby version and the status, type and code of the installed Kirby license. These values are considered sensitive information and should be protected by the `access.system` permission. The installed Kirby version and license data can be used by malicious actors during reconnaissance when planning a separate attack. ### Patches The problem has been patched in [Kirby 4.9.0](https://github.com/getkirby/kirby/releases/tag/4.9.0) and [Kirby 5.4.0](https://github.com/getkirby/kirby/releases/tag/5.4.0). Please update to one of these or a [later version](https://github.com/getkirby/kirby/releases) to fix the vulnerability. In all of the mentioned releases, we have protected the version and license properties of the `/api/system` endpoint with a check for the existing `access.system` permission. This ensures that the REST API only outputs information that should be accessible to the user via the Panel. ### Credits Kirby thanks @HuajiHD and @0x-bala for responsibly reporting the identified issue. |
Affected by 6 other vulnerabilities. |
|
VCID-g46n-k3pp-t3a5
Aliases: CVE-2026-34587 GHSA-jcjw-58rv-c452 |
Kirby has Server-Side Template Injection (SSTI) via double template resolution in option rendering ### TL;DR This vulnerability affects all Kirby sites that use option fields (`checkboxes`, `color`, `multiselect`, `select`, `radio`, `tags` or `toggles`) with options from a query or API whose values may not be fully trusted. It also affects direct uses of the `OptionsApi` or `OptionsQuery` classes of Kirby's `Options` package from plugin or site code. The attack requires either an attacker in the group of authenticated Panel users or user interaction of another authenticated user. **This vulnerability is of high severity for affected sites.** Users' Kirby sites are *not* affected if they are not using any of the mentioned fields or the `Options` package, if all options are defined statically in the blueprints or if all dynamically gathered options are to be trusted. ---- ### Introduction Server-Side Template Injection vulnerabilities (SSTI) occur when user input is embedded in a template in an unsafe manner and results in remote code execution on the server. Injected user input is wrongly treated as a template command instead of as a literal string of text. This allows attackers to query arbitrary information from the affected system or call arbitrary methods to perform actions. In a Kirby site this can be used to access protected site information, alter site content or break site behavior. ### Impact Kirby provides field types (`checkboxes`, `color`, `multiselect`, `select`, `radio`, `tags` and `toggles`) that offer a fixed set of options from a configured list. This configured list can be statically defined in the blueprint or it can come from a Kirby query or (external) API source. Options coming from a query or API are treated as dynamic. Static options can contain queries in the form `{{ query }}` or `{< query >}` that are then evaluated to a static value. Because the queries are defined in the blueprint, they can be trusted and cannot be controlled by attackers. However, dynamic options can often not be trusted. This is why the "options from query" and "options from API" modes are intended to resolve the option values and text strings based on queries not defined within the data source but within the blueprint. Unfortunately, the results of these trusted queries on untrusted source data are run through the query parser a second time in affected Kirby releases. Because of the double-resolution of dynamic option values and text strings, attackers could place malicious query templates such as `{{ users.first.password }}` or `{{ page.delete }}` in the option sources such as page titles or external API data controlled by the attacker. These queries would then be executed when the field is loaded in the Panel. When the attacker directly accesses the respective Panel view, they could get access to information normally hidden from them. As the malicious query templates are loaded for all users, it could also lead to malicious write access when another user with a higher permission level accesses the manipulated Panel view. ### Patches The problem has been patched in [Kirby 4.9.0](https://github.com/getkirby/kirby/releases/tag/4.9.0) and [Kirby 5.4.0](https://github.com/getkirby/kirby/releases/tag/5.4.0). Please update to one of these or a [later version](https://github.com/getkirby/kirby/releases) to fix the vulnerability. In all of the mentioned releases, Kirby has updated the `Options` logic to no longer double-resolve queries in option values coming from `OptionsQuery` or `OptionsApi` sources. Kirby now only resolves queries that are directly configured in the blueprints. ### Credits Kirby thanks to @offset for responsibly reporting the identified issue. |
Affected by 6 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-h2gp-rqt7-ckdf
Aliases: CVE-2026-42174 GHSA-39cp-6679-8xv2 |
Kirby CMS doesn't gate user avatar creation, replacement and deletion with user update permissions ### TL;DR This vulnerability affects all Kirby sites where users of a particular role have no permission to update user information (`user.update` or `users.update` permission is disabled). This can be due to configuration in the blueprint(s) of the acting users, via `options` in the blueprint(s) of the target users or via a combination of both settings. Kirby sites are *not* affected if they intend all users of the site to be able to upload, replace or delete user avatars. The vulnerability can only be exploited by authenticated users. ---- ### 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. ### 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 using the `options` feature (for user models again in the user blueprints). The permissions and options together control the authorization of user actions. Kirby provides the `user.update` and `users.update` permissions (among others) that control the authorization to update user information for the user's own data or the data of other users respectively. User files are separately gated by the `files.create`, `files.replace` and `files.delete` permissions (among others). In affected releases, Kirby only checked the `files.create` and `files.delete` permissions during changes to user avatars. Even though avatars are an integral part of the user profile, they were not covered by the `user.update` and `users.update` permissions. This allowed users with just file permissions to create, replace or delete user avatars. ### Patches The problem has been patched in [Kirby 4.9.0](https://github.com/getkirby/kirby/releases/tag/4.9.0) and [Kirby 5.4.0](https://github.com/getkirby/kirby/releases/tag/5.4.0). Please update to one of these or a [later version](https://github.com/getkirby/kirby/releases) to fix the vulnerability. In all of the mentioned releases, we have added additional permission checks for `user.update`/`users.update` when a user avatar is created, replaced or deleted. These permission checks apply in addition to the file permission checks (`files.create`, `files.replace` and `files.delete`). When a user avatar is replaced with a file of the same type, Kirby now consistently checks the `files.replace` permission instead of a combination of `files.create` and `files.delete`. |
Affected by 6 other vulnerabilities. |
|
VCID-hsgj-2c1x-cuhu
Aliases: CVE-2026-42069 GHSA-2h7v-4372-f6x2 |
Kirby CMS's read access to site, user and role information is not gated by permissions ### TL;DR This vulnerability affects all Kirby sites that might have potential attackers in the group of authenticated Panel users. **This vulnerability is of high severity for affected sites.** Sites using Kirby are *not* affected if they intend all users of the site to be able to list and access the site model and all users and roles, including the content stored within these models. Write actions are *not* affected by this vulnerability as they were gated by permissions before. ---- ### 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. ### 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. In affected releases, Kirby did not provide permission settings that control the access to the site model as well as to users and user roles. If the site developer disabled all permissions via the wildcard `"*": false` setting, this only disabled the actions that were explicitly gated by existing permissions. To be specific, the following permissions were missing in affected releases and have been added in the patches: - `site.access` - `user.access` and `users.access` (for the own user and other users respectively) - `user.list` and `users.list` (for the own user and other users respectively) Access to role information such as the list of existing roles, their names and descriptions as well as their configured permissions were also not gated by user-based permissions. ### Patches The problem has been patched in [Kirby 4.9.0](https://github.com/getkirby/kirby/releases/tag/4.9.0) and [Kirby 5.4.0](https://github.com/getkirby/kirby/releases/tag/5.4.0). Please update to one of these or a [later version](https://github.com/getkirby/kirby/releases) to fix the vulnerability. In all of the mentioned releases, Kirby has added the missing permissions that are listed in the "Impact" section. The `user.access` and `users.access` permissions also take effect on the access to the user's own role and to other roles respectively. ### Credits Kirby thanks @HuajiHD for responsibly reporting the identified issue. |
Affected by 6 other vulnerabilities. |
|
VCID-mhvv-3qdd-qfax
Aliases: CVE-2026-41325 GHSA-6gqr-mx34-wh8r |
Kirby is vulnerable to authorization bypass during page, file and user creation via blueprint injection ### TL;DR This vulnerability affects all Kirby sites where users of a particular role have no permission to create pages, files or users (`pages.create`, `files.create` or `users.create` permission is disabled). This can be due to configuration in the user blueprint(s), via `options` in the model blueprint(s) or via a combination of both settings. **This vulnerability is of high severity for affected sites.** Developers' Kirby sites are *not* affected if they intend all users of their site to be able to create pages, files and users. 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. Kirby provides the `pages.create`, `files.create` and `users.create` permissions (among others). These permissions can again be set in the user blueprint and/or in the blueprint of the target model via `options`. In affected releases, Kirby allowed to override the `options` during the creation of pages, files and users by injecting custom dynamic blueprint configuration into the model data. The injected `options` could include `'create' => true`, which then caused an override of the permissions and options configured by the site developer in the user and model blueprints. ### Patches The problem has been patched in [Kirby 4.9.0](https://github.com/getkirby/kirby/releases/tag/4.9.0) and [Kirby 5.4.0](https://github.com/getkirby/kirby/releases/tag/5.4.0). Please update to one of these or a [later version](https://github.com/getkirby/kirby/releases) to fix the vulnerability. In all of the mentioned releases, we have updated the normalization code that is used during the creation of pages, files and users to include a filter for the `blueprint` property. This prevents the injection of dynamic blueprint configuration into the creation request. ### Credits Kirby thanks @offset for responsibly reporting the identified issue. |
Affected by 6 other vulnerabilities. |
|
VCID-n212-9fuw-bbbn
Aliases: CVE-2026-45368 GHSA-qvjf-922g-pj44 |
Kirby CMS vulnerable to cross-site scripting (XSS) from links in KirbyTags and image blocks in the site frontend ### TL;DR This vulnerability affects all Kirby sites that allow the use of the `(link: …)` KirbyTag, the `link:` parameter of the `(image: …)` KirbyTag, the built-in `image` block with a link or the HTML importer for blocks, when content is authored by users who may not be fully trusted. The attack requires an authenticated Panel user with update permission to any `textarea` or `blocks` field, or write access to content files through another vector (e.g. a frontend form or content sync pipeline). Another attack vector is the use of `Html::a()` or `Html::link()` with untrusted user input. **This vulnerability is of high severity for affected sites.** Kirby sites are *not* affected if none of the mentioned KirbyTags or block types are used, or if every user who can edit content is fully trusted. The attack only surfaces in the site frontend (i.e. in its templates). The Panel itself is unaffected and will not execute JavaScript that was injected into the `textarea` or `blocks` field content. --- ### Introduction Cross-site scripting (XSS) is a type of vulnerability that allows to execute any kind of JavaScript code inside the site frontend or Panel session of the same or other users. In the Panel, a harmful script can for example trigger requests to Kirby's API with the permissions of the victim. In a *stored* XSS attack, the malicious payload is saved into the content data and has the potential to affect other users or site visitors. Such vulnerabilities are critical if a consuming application might have potential attackers in its group of authenticated Panel users. They can escalate their privileges if they get access to the Panel session of an admin user. Depending on the site, other JavaScript-powered attacks are possible. A specific class of stored XSS exploits the `javascript:` URI scheme in HTML `<a href>` attributes. When a browser processes a click action on a link with `href="javascript:…"`, it executes the value as JavaScript in the origin of the current page. Because the site usually runs on the same origin as the Panel API, a successful exploit in the site frontend can give the attacker full control of the victim's Panel session. ### Affected components Kirby provides four first-party renderers that produce `<a href="…">` output from editor-supplied field values: 1. The `(link: …)` KirbyTag 2. The `link:` parameter of the `(image: …)` KirbyTag, when the parameter does not resolve to a known file or `'self'` 3. The link field of the built-in `image` block 4. The HTML importer for the blocks field (which accepted the same malicious input as the `image` block link field) ### Impact In affected releases, the underlying URL methods for these components did not filter out malicious URL values that resolve to script execution. While simple `javascript:` URLs were already deactivated by treating them as a relative path and prepending a single slash to the URL, the use of URLs of the format `javascript://x%0A…` bypasses this protection. The `vbscript:`, `data:`, `livescript:`, `mocha:` and `jar:` schemes are affected by the same underlying gap. The vulnerability allows attackers to inject malicious links into content. The malicious links would then be rendered on the site frontend. If a site visitor or logged in user browsing the site would click such a link, the malicious script code would then be executed in the browser. ### Patches The problem has been patched in [Kirby 4.9.1](https://github.com/getkirby/kirby/releases/tag/4.9.1) and [Kirby 5.4.1](https://github.com/getkirby/kirby/releases/tag/5.4.1). Please update to one of these or a [later version](https://github.com/getkirby/kirby/releases) to fix the vulnerability. In all of the mentioned releases, a new `Url::hasDangerousScheme()` method detects URI schemes that must never appear in a rendered `href` or `src` attribute (`javascript:`, `vbscript:`, `livescript:`, `mocha:`, `jar:`, `data:`). `Url::isAbsolute()` now returns `false` for any URL that `hasDangerousScheme()` identifies as dangerous, so the URL component no longer passes these values through `makeAbsolute()` unchanged. `Html::link()` now replaces the `href` with an empty string when a dangerous scheme is detected, so the rendered `<a>` tag links back to the current page rather than executing the injected script. The HTML importer for blocks strips link targets with a dangerous scheme. Due to the hardening in these underlying URL methods, the affected KirbyTags and block no longer allow dangerous schemes in link targets. ### Credits Kirby thanks @offset for responsibly reporting the identified issue. |
Affected by 0 other vulnerabilities. |
|
VCID-naeq-jec3-1bht
Aliases: CVE-2025-65012 GHSA-84hf-8gh5-575j |
Kirby CMS has cross-site scripting (XSS) in the changes dialog The "Changes" dialog in the Panel displays all content models (pages, files, users) with changed content, i.e. with content that has not yet been published. Each changed model is listed with its preview image/icon and its title/name. Attackers could change the title of any page or the name of any user to a malicious string. Then they could modify any content field of the same model without saving, making the model a candidate for display in the "Changes" dialog. If another authenticated user subsequently opened the dialog in their Panel, the malicious code would be executed. |
Affected by 9 other vulnerabilities. |
|
VCID-nt5x-k3wp-u3hu
Aliases: CVE-2026-32870 GHSA-9wfj-c55w-j9qr |
Kirby has XML injection in its XML creator toolkit ### TL;DR This vulnerability only affects Kirby sites that use the `Xml` data handler (e.g. `Data::encode($string, 'xml')`) or the `Xml::create()`, `Xml::tag()` or `Xml::value()` method(s) in site or plugin code. The Kirby core does not use any of the affected methods. If consumers use an affected method and cannot rule out input to these methods controlled by an attacker, Kirby strongly recommends that they update to a patch release. ---- ### Introduction XML strings contain structured data in tags and attributes. Depending on the used XML schema, this data can carry specific meaning that can lead to actions in other systems that parse and act on the XML data. Tags and attributes are detected based on their specific syntax, which includes characters such as `<`, `>`, `"`, and `&`. If these characters are to be used verbatim in text within the XML string, they can be escaped using a `<![CDATA[ ]]>` block. XML injection is an attack on a system generating or parsing XML files. By injecting special characters into input data, XML output with a malicious meaning could be generated by a vulnerable system. ### Impact Kirby's `Xml::value()` method has special handling for `<![CDATA[ ]]>` blocks. If the input value is already valid `CDATA`, it is not escaped a second time but allowed to pass through. However it was possible to trick this check into allowing values that only *contained* a valid `CDATA` block but also contained other structured data outside of the `CDATA` block. This structured data would then also be allowed to pass through, circumventing the value protection. The `Xml::value()` method is used in `Xml::tag()`, `Xml::create()` and in the `Xml` data handler (e.g. `Data::encode($string, 'xml')`). Both the vulnerable methods and the data handler are not used in the Kirby core. However they may be used in site or plugin code, e.g. to create XML strings from input data. If those generated files are passed to another implementation that assigns specific meaning to the XML schema, manipulation of this system's behavior is possible. Kirby sites that don't use XML generation in site or plugin code are *not* affected. ### Patches The problem has been patched in [Kirby 4.9.0](https://github.com/getkirby/kirby/releases/tag/4.9.0) and [Kirby 5.4.0](https://github.com/getkirby/kirby/releases/tag/5.4.0). Please update to one of these or a [later version](https://github.com/getkirby/kirby/releases) to fix the vulnerability. In all of the mentioned releases, Kirby has added additional checks that only allow unchanged `CDATA` passthrough if the entire string is made up of valid `CDATA` blocks and no structured data. This protects all uses of the method against the described vulnerability. ### Credits Kirby thanks to Patrick Falb (@dapatrese) at [FORMER 03](https://former03.de/) for responsibly reporting the identified issue. |
Affected by 6 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-pvx9-24pb-bba7
Aliases: CVE-2026-44176 GHSA-2xw4-v2wx-hqq9 |
Kirby CMS's `pages.access` permission is not checked during rendering of page drafts ### TL;DR This vulnerability affects all Kirby sites 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), via `options` in the model blueprint(s) or via a combination of both settings. Kirby sites are *not* affected if they intend all users of the site to be able to access all page drafts of the site. 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 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. 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 path resolver for the main CMS router. The resolver takes an input path from the requested URL and determines which model (page or file) should be rendered. When a path is requested that points to a page draft, the resolver checks that the request either contains a valid preview token or is authenticated by a valid user. ### Impact In affected releases, Kirby allowed page drafts to be rendered if any valid user was authenticated, even if that user did not have access to the specific page model. Authenticated attackers with knowledge of the full path to an existing page draft could then access the rendered frontend page. This could lead to the disclosure of sensitive information, e.g. ahead of the launch of a new product or post. ### Patches The problem has been patched in [Kirby 4.9.1](https://github.com/getkirby/kirby/releases/tag/4.9.1) and [Kirby 5.4.1](https://github.com/getkirby/kirby/releases/tag/5.4.1). Please update to one of these or a [later version](https://github.com/getkirby/kirby/releases) to fix the vulnerability. In all of the mentioned releases, Kirby has added a check that verifies that the requested page draft is accessible to the current user before rendering the draft template. ### Credits Kirby thank to @adrgs for responsibly reporting the identified issue. |
Affected by 0 other vulnerabilities. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| This package is not known to fix vulnerabilities. | ||