Search for packages
| purl | pkg:composer/getkirby/cms@3.2.2 |
| Next non-vulnerable version | 4.9.1 |
| Latest non-vulnerable version | 6.0.0-alpha.1 |
| Risk | 10.0 |
| Vulnerability | Summary | Fixed by |
|---|---|---|
|
VCID-1zg8-cndr-73hk
Aliases: CVE-2025-31493 GHSA-x275-h9j4-7p4h |
Kirby vulnerable to path traversal of collection names during file system lookup The missing path traversal check allowed attackers to navigate and access all files on the server that were accessible to the PHP process, including files outside of the collections root or even outside of the Kirby installation. PHP code within such files was executed. Such attacks first require an attack vector in the site code that is caused by dynamic collection names, such as `collection('tags-' . get('tags'))`. It generally also requires knowledge of the site structure and the server's file system by the attacker, although it can be possible to find vulnerable setups through automated methods such as fuzzing. In a vulnerable setup, this could cause damage to the confidentiality and integrity of the server, for example: - it could allow the attacker to build a map of the server's file system for subsequent attacks, - it could allow access to configuration files that may contain sensitive information like security tokens or - it could cause the unintended execution of PHP scripts. |
Affected by 8 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 8 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 8 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
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 5 other vulnerabilities. Affected by 6 other vulnerabilities. |
|
VCID-6zd1-91p6-tkfm
Aliases: CVE-2021-32735 GHSA-2f2w-349x-vrqm |
Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') Kirby is a content management system. In Kirby CMS versions 3.5.5 and 3.5.6, the Panel's `ListItem` component (used in the pages and files section for example) displayed HTML in page titles as it is. This could be used for cross-site scripting (XSS) attacks. Malicious authenticated Panel users can escalate their privileges if they get access to the Panel session of an admin user. Visitors without Panel access can use the attack vector if the site allows changing site data from a frontend form. Kirby 3.5.7 patches the vulnerability. As a partial workaround, site administrators can protect against attacks from visitors without Panel access by validating or sanitizing provided data from the frontend form. |
Affected by 26 other vulnerabilities. Affected by 27 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 5 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 6 other vulnerabilities. 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 5 other vulnerabilities. Affected by 6 other vulnerabilities. |
|
VCID-ecrh-8521-xuf4
Aliases: CVE-2021-29460 GHSA-qgp4-5qx6-548g |
Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') Kirby is an open source CMS. An editor with write access to the Kirby Panel can upload an SVG file that contains harmful content like `<script>` tags. The direct link to that file can be sent to other users or visitors of the site. If the victim opens that link in a browser where they are logged in to Kirby, the script will run and can for example trigger requests to Kirby's API with the permissions of the victim. This vulnerability is critical if you might have potential attackers in your group of authenticated Panel users, as they can escalate their privileges if they get access to the Panel session of an admin user. Depending on your site, other JavaScript-powered attacks are possible. Visitors without Panel access can only use this attack vector if your site allows SVG file uploads in frontend forms and you don't already sanitize uploaded SVG files. The problem has been patched in Kirby 3.5.4. Please update to this or a later version to fix the vulnerability. Frontend upload forms need to be patched separately depending on how they store the uploaded file(s). If you use `File::create()`, you are protected by updating to 3.5.4+. As a work around you can disable the upload of SVG files in your file blueprints. |
Affected by 27 other vulnerabilities. |
|
VCID-fdv5-99h7-tugz
Aliases: CVE-2020-26253 GHSA-2ccx-2gf3-8xvv |
Origin Validation Error Kirby is a CMS. In Kirby CMS (getkirby/cms) before version 3.3.6, and Kirby Panel before version 2.5.14 there is a vulnerability in which the admin panel may be accessed if hosted on a .dev domain. In order to protect new installations on public servers that don't have an admin account for the Panel yet, we block account registration there by default. This is a security feature, which we implemented years ago in Kirby 2. It helps to avoid that you forget registering your first admin account on a public server. In this case – without our security block – someone else might theoretically be able to find your site, find out it's running on Kirby, find the Panel and then register the account first. It's an unlikely situation, but it's still a certain risk. To be able to register the first Panel account on a public server, you have to enforce the installer via a config setting. This helps to push all users to the best practice of registering your first Panel account on your local machine and upload it together with the rest of the site. This installation block implementation in Kirby versions before 3.3.6 still assumed that .dev domains are local domains, which is no longer true. In the meantime, those domains became publicly available. This means that our installation block is no longer working as expected if you use a .dev domain for your Kirby site. Additionally the local installation check may also fail if your site is behind a reverse proxy. You are only affected if you use a .dev domain or your site is behind a reverse proxy and you have not yet registered your first Panel account on the public server and someone finds your site and tries to login at `yourdomain.dev/panel` before you register your first account. You are not affected if you have already created one or multiple Panel accounts (no matter if on a .dev domain or behind a reverse proxy). The problem has been patched in Kirby 3.3.6. Please upgrade to this or a later version to fix the vulnerability. |
Affected by 26 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 5 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 6 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-ge49-hn25-eqba
Aliases: CVE-2023-38488 GHSA-x5mr-p6v4-wp93 |
Incorrect Authorization Kirby is a content management system. A vulnerability in versions prior to 3.5.8.3, 3.6.6.3, 3.7.5.2, 3.8.4.1, and 3.9.6 affects all Kirby sites that might have potential attackers in the group of authenticated Panel users or that allow external visitors to update a Kirby content file (e.g. via a contact or comment form). Kirby sites are *not* affected if they don't allow write access for untrusted users or visitors. A field injection in a content storage implementation is a type of vulnerability that allows attackers with content write access to overwrite content fields that the site developer didn't intend to be modified. In a Kirby site this can be used to alter site content, break site behavior or inject malicious data or code. The exact security risk depends on the field type and usage. Kirby stores content of the site, of pages, files and users in text files by default. The text files use Kirby's KirbyData format where each field is separated by newlines and a line with four dashes (`----`). When reading a KirbyData file, the affected code first removed the Unicode BOM sequence from the file contents and afterwards split the content into fields by the field separator. When writing to a KirbyData file, field separators in field data are escaped to prevent user input from interfering with the field structure. However this escaping could be tricked by including a Unicode BOM sequence in a field separator (e.g. `--\xEF\xBB\xBF--`). When writing, this was not detected as a separator, but because the BOM was removed during reading, it could be abused by attackers to inject other field data into content files. Because each field can only be defined once per content file, this vulnerability only affects fields in the content file that were defined above the vulnerable user-writable field or not at all. Fields that are defined below the vulnerable field override the injected field content and were therefore already protected. The problem has been patched in Kirby 3.5.8.3, 3.6.6.3, 3.7.5.2, 3.8.4.1, and 3.9.6. In all of the mentioned releases, the maintainers have fixed the affected code to only remove the Unicode BOM sequence at the beginning of the file. This fixes this vulnerability both for newly written as well as for existing content files. |
Affected by 16 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 16 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 16 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 16 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 16 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 5 other vulnerabilities. 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 5 other vulnerabilities. Affected by 6 other vulnerabilities. |
|
VCID-kfkm-1a5s-jyf9
Aliases: CVE-2023-38491 GHSA-8fv7-wq38-f5c9 |
Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting') Kirby is a content management system. A vulnerability in versions prior to 3.5.8.3, 3.6.6.3, 3.7.5.2, 3.8.4.1, and 3.9.6 affects all Kirby sites that might have potential attackers in the group of authenticated Panel users or that allow external visitors to upload an arbitrary file to the content folder. Kirby sites are not affected if they don't allow file uploads for untrusted users or visitors or if the file extensions of uploaded files are limited to a fixed safe list. The attack requires user interaction by another user or visitor and cannot be automated. An editor with write access to the Kirby Panel could upload a file with an unknown file extension like `.xyz` that contains HTML code including harmful content like `<script>` tags. The direct link to that file could be sent to other users or visitors of the site. If the victim opened that link in a browser where they are logged in to Kirby and the file had not been opened by anyone since the upload, Kirby would not be able to send the correct MIME content type, instead falling back to `text/html`. The browser would then run the script, which could for example trigger requests to Kirby's API with the permissions of the victim. The issue was caused by the underlying `Kirby\Http\Response::file()` method, which didn't have an explicit fallback if the MIME type could not be determined from the file extension. If you use this method in site or plugin code, these uses may be affected by the same vulnerability. The problem has been patched in Kirby 3.5.8.3, 3.6.6.3, 3.7.5.2, 3.8.4.1, and 3.9.6. In all of the mentioned releases, the maintainers have fixed the affected method to use a fallback MIME type of `text/plain` and set the `X-Content-Type-Options: nosniff` header if the MIME type of the file is unknown. |
Affected by 16 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 16 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 16 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 16 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 16 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 5 other vulnerabilities. Affected by 6 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 5 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 6 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-pnk6-vjcp-u7aa
Aliases: CVE-2023-38489 GHSA-5mvj-rvp8-rf45 |
Kirby is a content management system. A vulnerability in versions prior to 3.5.8.3, 3.6.6.3, 3.7.5.2, 3.8.4.1, and 3.9.6 affects all Kirby sites with user accounts (unless Kirby's API and Panel are disabled in the config). It can only be abused if a Kirby user is logged in on a device or browser that is shared with potentially untrusted users or if an attacker already maliciously used a previous password to log in to a Kirby site as the affected user. Insufficient Session Expiration is when a web site permits an attacker to reuse old session credentials or session IDs for authorization. In the variation described in this advisory, it allows attackers to stay logged in to a Kirby site on another device even if the logged in user has since changed their password. Kirby does not invalidate user sessions that were created with a password that was since changed by the user or by a site admin. If a user changed their password to lock out an attacker who was already in possession of the previous password or of a login session on another device or browser, the attacker would not be reliably prevented from accessing the Kirby site as the affected user. The problem has been patched in Kirby 3.5.8.3, 3.6.6.3, 3.7.5.2, 3.8.4.1, and 3.9.6. In all of the mentioned releases, the maintainers have updated the authentication implementation to keep track of the hashed password in each active session. If the password changed since the login, the session is invalidated. To enforce this fix even if the vulnerability was previously abused, all users are logged out from the Kirby site after updating to one of the patched releases. |
Affected by 16 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 16 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 16 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 16 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 16 other vulnerabilities. |
|
VCID-s33b-8zp5-yyaa
Aliases: GHSA-fr72-9665-w3gr |
Duplicate Advisory: Unrestricted file upload of user avatar images ## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-xrvh-rvc4-5m43. This link is maintained to preserve external references. ## Original Description An arbitrary file upload vulnerability in the Profile Image module of Kirby CMS v4.1.0 allows attackers to execute arbitrary code via a crafted PDF file. |
Affected by 11 other vulnerabilities. |
|
VCID-sbfh-v9uy-u3cp
Aliases: CVE-2024-26483 GHSA-xrvh-rvc4-5m43 |
Kirby vulnerable to unrestricted file upload of user avatar images ### TL;DR This vulnerability affects all Kirby sites that might have potential attackers in the group of authenticated Panel users. The attack requires user interaction by another user or visitor and *cannot* be automated. ---- ### Introduction Unrestricted upload of files with a dangerous type is a type of vulnerability that allows to circumvent expectations and protections in the server setup or backend code. Uploaded files are not checked for their compliance with the intended purpose of the upload target, which can introduce secondary attack vectors. While the vulnerability described here does *not* allow critical attacks like remote code execution (RCE), it can still be abused to upload unexpected file types that could for example make it possible to perform cross-site scripting (XSS) attacks. ### Impact Users with Panel access can upload a user avatar in their own account view. This avatar is intended to be an image, however the file type or file extension was not validated on the backend. This effectively allowed to upload many types of files that would then be stored with the filename `profile` and the provided file extension. While the upload is protected against dangerous file types such as HTML files or executable PHP files, this could be abused to upload unexpected files such as PDFs that would then be available via a direct link. These links could be shared to other users. ### Patches The problem has been patched in [Kirby 3.6.6.5](https://github.com/getkirby/kirby/releases/tag/3.6.6.5), [Kirby 3.7.5.4](https://github.com/getkirby/kirby/releases/tag/3.7.5.4), [Kirby 3.8.4.3](https://github.com/getkirby/kirby/releases/tag/3.8.4.3), [Kirby 3.9.8.1](https://github.com/getkirby/kirby/releases/tag/3.9.8.1), [Kirby 3.10.0.1](https://github.com/getkirby/kirby/releases/tag/3.10.0.1), and [Kirby 4.1.1](https://github.com/getkirby/kirby/releases/tag/4.1.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, we have added validations that prevent any files that don't have an image file extension or MIME type from being uploaded as a user avatar. ### Credits Thanks to Natwara Archeepsamooth (@PlyNatwara) for responsibly reporting the identified issue. |
Affected by 11 other vulnerabilities. Affected by 1 other vulnerability. Affected by 11 other vulnerabilities. Affected by 1 other vulnerability. Affected by 11 other vulnerabilities. Affected by 1 other vulnerability. Affected by 11 other vulnerabilities. Affected by 1 other vulnerability. Affected by 11 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 11 other vulnerabilities. |
|
VCID-seme-4ery-6qbp
Aliases: CVE-2025-30207 GHSA-9p3p-w5jf-8xxg |
Kirby vulnerable to path traversal in the router for PHP's built-in server The missing path traversal check allowed attackers to navigate all files on the server that were accessible to the PHP process, including files outside of the Kirby installation. The vulnerable implementation delegated all existing files to PHP, including existing files outside of the document root. This leads to a different response that allows attackers to determine whether the requested file exists. Because Kirby's router only delegates such requests to PHP and does not load or execute them, contents of the files were not exposed as PHP treats requests to files outside of the document root as invalid. |
Affected by 8 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 8 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 8 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-sjc3-ztkw-u7gx
Aliases: CVE-2020-26255 GHSA-g3h8-cg9x-47qw |
Unrestricted Upload of File with Dangerous Type Kirby is a CMS. In Kirby CMS (getkirby/cms) before version 3.4.5, and Kirby Panel before version 2.5.14 , an editor with full access to the Kirby Panel can upload a PHP .phar file and execute it on the server. This vulnerability is critical if you might have potential attackers in your group of authenticated Panel users, as they can gain access to the server with such a Phar file. Visitors without Panel access *cannot* use this attack vector. The problem has been patched in Kirby 2.5.14 and Kirby 3.4.5. Please update to one of these or a later version to fix the vulnerability. Note: Kirby 2 reaches end of life on December 31, 2020. We therefore recommend to upgrade your Kirby 2 sites to Kirby 3. If you cannot upgrade, we still recommend to update to Kirby 2.5.14. |
Affected by 25 other vulnerabilities. |
|
VCID-t7he-gjus-hyfm
Aliases: CVE-2023-38490 GHSA-q386-w6fg-gmgp |
Improper Restriction of Recursive Entity References in DTDs ('XML Entity Expansion') Kirby is a content management system. A vulnerability in versions prior to 3.5.8.3, 3.6.6.3, 3.7.5.2, 3.8.4.1, and 3.9.6 only affects Kirby sites that use the `Xml` data handler (e.g. `Data::decode($string, 'xml')`) or the `Xml::parse()` method in site or plugin code. The Kirby core does not use any of the affected methods. XML External Entities (XXE) is a little used feature in the XML markup language that allows to include data from external files in an XML structure. If the name of the external file can be controlled by an attacker, this becomes a vulnerability that can be abused for various system impacts like the disclosure of internal or confidential data that is stored on the server (arbitrary file disclosure) or to perform network requests on behalf of the server (server-side request forgery, SSRF). Kirby's `Xml::parse()` method used PHP's `LIBXML_NOENT` constant, which enabled the processing of XML external entities during the parsing operation. The `Xml::parse()` method is used in the `Xml` data handler (e.g. `Data::decode($string, 'xml')`). Both the vulnerable method and the data handler are not used in the Kirby core. However they may be used in site or plugin code, e.g. to parse RSS feeds or other XML files. If those files are of an external origin (e.g. uploaded by a user or retrieved from an external URL), attackers may be able to include an external entity in the XML file that will then be processed in the parsing process. Kirby sites that don't use XML parsing in site or plugin code are *not* affected. The problem has been patched in Kirby 3.5.8.3, 3.6.6.3, 3.7.5.2, 3.8.4.1, and 3.9.6. In all of the mentioned releases, the maintainers have removed the `LIBXML_NOENT` constant as processing of external entities is out of scope of the parsing logic. This protects all uses of the method against the described vulnerability. |
Affected by 16 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 16 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 16 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 16 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 16 other vulnerabilities. |
|
VCID-umm8-7cx6-4fcu
Aliases: CVE-2024-26482 GHSA-qv4x-v2v4-f8p9 |
Kirby CMS HTML injection vulnerability An HTML injection vulnerability in the Edit Content Layout module of Kirby CMS v4.1.0 allows attackers to execute arbitrary code via a crafted payload. | There are no reported fixed by versions. |
|
VCID-w47w-xzfq-7bdk
Aliases: CVE-2024-41964 GHSA-jm9m-rqr3-wfmh |
Kirby has insufficient permission checks in the language settings The missing permission checks allowed attackers with Panel access to manipulate the language definitions. The language definitions are at the core of multi-language content in Kirby. Unauthorized modifications with malicious intent can cause significant damage, for example: - If the `languages` option was enabled but no language exists, creating the first language will switch Kirby to multi-language mode. - Deleting an existing language will lead to content loss of all translated content in that language. Deleting the last language will switch Kirby to single-language mode. - Updating a language allows to change the metadata including the language slug (used in page URLs) and language variables. It also allows to change the default language, which will cause Kirby to use the new default language's content as a fallback for non-existing translations. Depending on the site code, the result of such actions can cause loss of site availability (e.g. error messages in the site frontend) or integrity (due to changed URLs or removed translations). |
Affected by 10 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 10 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 10 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 10 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 11 other vulnerabilities. Affected by 10 other vulnerabilities. Affected by 10 other vulnerabilities. |
|
VCID-w4e7-nn14-77hf
Aliases: CVE-2023-38492 GHSA-3v6j-v3qc-cxff |
Allocation of Resources Without Limits or Throttling Kirby is a content management system. A vulnerability in versions prior to 3.5.8.3, 3.6.6.3, 3.7.5.2, 3.8.4.1, and 3.9.6 affects all Kirby sites with user accounts (unless Kirby's API and Panel are disabled in the config). The real-world impact of this vulnerability is limited, however we still recommend to update to one of the patch releases because they also fix more severe vulnerabilities. Kirby's authentication endpoint does not limit the password length. This allowed attackers to provide a password with a length up to the server's maximum request body length. Validating that password against the user's actual password requires hashing the provided password, which requires more CPU and memory resources (and therefore processing time) the longer the provided password gets. This could be abused by an attacker to cause the website to become unresponsive or unavailable. Because Kirby comes with a built-in brute force protection, the impact of this vulnerability is limited to 10 failed logins from each IP address and 10 failed logins for each existing user per hour. The problem has been patched in Kirby 3.5.8.3, 3.6.6.3, 3.7.5.2, 3.8.4.1, and 3.9.6. In all of the mentioned releases, the maintainers have added password length limits in the affected code so that passwords longer than 1000 bytes are immediately blocked, both when setting a password and when logging in. |
Affected by 16 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 16 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 16 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 16 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 16 other vulnerabilities. |
|
VCID-w8k5-mcu9-zuh3
Aliases: CVE-2024-26481 GHSA-57f2-8p89-66x6 |
Kirby vulnerable to self cross-site scripting (self-XSS) in the URL field ### TL;DR This vulnerability affects Kirby sites that use the [URL field](https://getkirby.com/docs/reference/panel/fields/url) in any blueprint. A successful attack commonly requires knowledge of the content structure by the attacker as well as social engineering of a user with access to the Panel. The attack *cannot* be automated. The vulnerability is also limited to self-XSS and *cannot* directly affect other users or visitors of the site. ---- ### Introduction Cross-site scripting (XSS) is a type of vulnerability that allows to execute any kind of JavaScript code inside the 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. Self cross-site scripting (self-XSS, also called reflected XSS) typically involves a user inadvertently executing malicious code within their own context, often through social engineering techniques. This can occur when a user is tricked into pasting and executing malicious JavaScript code into the browser's developer console, address bar or form fields. Such vulnerabilities are critical as they allow attackers to gain access to the system or to escalate their privileges if they get access to the Panel session of an admin user. Depending on your site, other JavaScript-powered attacks are possible. ### Impact The URL field allows users to open the entered link in a new tab by clicking the link icon inside the field. This can be used to quickly verify whether the entered URL is functional and correct. In affected versions, Kirby copied the entered URL into the link target of that link button without validating or sanitizing the link. This could be abused by attackers with a `javascript:` URL that would then be executed in the user's context when the link button was clicked with <kbd>Ctrl+Click</kbd>/<kbd>Cmd+Click</kbd>. ### Patches The problem has been patched in [Kirby 3.6.6.5](https://github.com/getkirby/kirby/releases/tag/3.6.6.5), [Kirby 3.7.5.4](https://github.com/getkirby/kirby/releases/tag/3.7.5.4), [Kirby 3.8.4.3](https://github.com/getkirby/kirby/releases/tag/3.8.4.3), [Kirby 3.9.8.1](https://github.com/getkirby/kirby/releases/tag/3.9.8.1), [Kirby 3.10.0.1](https://github.com/getkirby/kirby/releases/tag/3.10.0.1), and [Kirby 4.1.1](https://github.com/getkirby/kirby/releases/tag/4.1.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, we have changed the URL field to only make the link button clickable if the entered URL is valid and safe. ### Credits Thanks to Natwara Archeepsamooth (@PlyNatwara) for responsibly reporting the identified issue. |
Affected by 11 other vulnerabilities. Affected by 1 other vulnerability. Affected by 11 other vulnerabilities. Affected by 1 other vulnerability. Affected by 11 other vulnerabilities. Affected by 1 other vulnerability. Affected by 11 other vulnerabilities. Affected by 1 other vulnerability. Affected by 11 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 11 other vulnerabilities. |
|
VCID-wa88-mnaj-j7gx
Aliases: CVE-2022-36037 GHSA-3f89-869f-5w76 |
Cross-site scripting from dynamic options in the multiselect field ### Introduction Cross-site scripting (XSS) is a type of vulnerability that allows to execute any kind of JavaScript code inside the 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. Such vulnerabilities are critical if you might have potential attackers in your group of authenticated Panel users. They can escalate their privileges if they get access to the Panel session of an admin user. Depending on your site, other JavaScript-powered attacks are possible. ### Impact The multiselect field allows to select tags from an autocompleted list. Unfortunately, the Panel in Kirby 3.5 used HTML rendering for the raw option value. This allowed **attackers with influence on the options source** (e.g. content of sibling pages or an API endpoint) to inject HTML code. If a page in the Panel that uses the manipulated multiselect options was visited by a victim and the victim opened the autocomplete dropdown, the victim's browser will then have rendered this malicious HTML code. You are *not* affected by this vulnerability if you don't use the multiselect field or only use it with options that cannot be manipulated by attackers. ### Patches The problem has been patched in [Kirby 3.5.8.1](https://github.com/getkirby/kirby/releases/tag/3.5.8.1). Please update to this or a [later version](https://github.com/getkirby/kirby/releases) to fix the vulnerability. ### Workarounds We recommend to update to the patch release. If you cannot update immediately, you can work around the issue by disabling the multiselect field. This can be done by uncommenting this field from all your blueprints. |
Affected by 23 other vulnerabilities. Affected by 0 other vulnerabilities. |
|
VCID-z6y7-rubq-8bdh
Aliases: CVE-2022-39315 GHSA-c27j-76xg-6x4f GMS-2022-5561 |
Kirby CMS vulnerable to user enumeration in the brute force protection ### TL;DR This vulnerability affects all Kirby sites with user accounts (unless Kirby's API and Panel are disabled in the config). It can only be exploited for targeted attacks because the attack does not scale to brute force. ---- ### Introduction User enumeration is a type of vulnerability that allows attackers to confirm which users are registered in a Kirby installation. This information can be abused for social engineering attacks against users of the site or to find out the organizational structure of the company. User enumeration attacks are performed by entering an existing and a non-existing user into the email address field of the login form. If the system returns a different response or behaves differently depending on whether the user exists, the attacker can enter unknown email addresses and use the different behavior as a clue for the (non-)existing user. ### Impact Kirby comes with a built-in brute force protection. By default, it will prevent further login attempts after 10 failed logins from a single IP address or of a single existing user. After every failed login attempt, Kirby inserts a random delay between one millisecond and two seconds to make automated attacks harder and to avoid leaking whether the user exists. Unfortunately, this random delay was not inserted after the brute force limit was reached. Because Kirby only tracks failed login attempts per email address for existing users but always tracks failed login attempts per IP address, this behavior could be abused by attackers for user enumeration. For this to work, an attacker would need to create login requests beyond the trials limit (which is 10 by default) from two or more IP addresses. After the trials limit was reached, the login form immediately blocked further requests for existing users, but not for invalid users. This exploit does not scale to brute force attacks because of the delay during the first 10 requests per user, the faint difference between the responses for valid and invalid users and the fact that code-based logins would send an email for every login attempt, which makes the attack easy to spot. The vulnerability is therefore only relevant for targeted attacks. ### Patches The problem has been patched in [Kirby 3.5.8.2](https://github.com/getkirby/kirby/releases/tag/3.5.8.2), [Kirby 3.6.6.2](https://github.com/getkirby/kirby/releases/tag/3.6.6.2), [Kirby 3.7.5.1](https://github.com/getkirby/kirby/releases/tag/3.7.5.1) and [Kirby 3.8.1](https://github.com/getkirby/kirby/releases/tag/3.8.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, we have rewritten the affected code so that the delay is also inserted after the brute force limit is reached. |
Affected by 0 other vulnerabilities. Affected by 16 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 13 other vulnerabilities. Affected by 0 other vulnerabilities. Affected by 13 other vulnerabilities. Affected by 21 other vulnerabilities. Affected by 21 other vulnerabilities. |
|
VCID-zakx-qtwy-gbba
Aliases: GHSA-w879-mxj5-c3wf |
Duplicate Advisory: Kirby vulnerable to self cross-site scripting (self-XSS) in the URL field ## Duplicate Advisory This advisory has been withdrawn because it is a duplicate of GHSA-57f2-8p89-66x6. This link is maintained to preserve external references. ## Original Description Kirby CMS v4.1.0 was discovered to contain a reflected cross-site scripting (XSS) vulnerability via the URL parameter. |
Affected by 11 other vulnerabilities. |
| Vulnerability | Summary | Aliases |
|---|---|---|
| This package is not known to fix vulnerabilities. | ||