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 and Kirby 5.4.0. Please update to one of these or a later version to fix the vulnerability.

In all of the mentioned releases, Kirby has added 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.

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 and Kirby 5.4.0. Please update to one of these or a later version to fix the vulnerability.

In all of the mentioned releases, 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.

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 and Kirby 5.4.0. Please update to one of these or a later version to fix the vulnerability.

In all of the mentioned releases, 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.

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 and Kirby 5.4.0. Please update to one of these or a later version to fix the vulnerability.

In all of the mentioned releases, 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.

An issue was discovered in Kirby 2.5.12. The delete page functionality suffers from a CSRF flaw. A remote attacker can craft a malicious CSRF page and force the user to delete a page.

TL;DR

This vulnerability affects Kirby sites that use the new link field and output the entered link without additional validation or sanitization.

The attack commonly requires user interaction by another user or visitor.

The link dialog of the writer field is not affected as the writer field content is automatically sanitized by the Kirby backend code. You are also already protected if you limit the acceptable link types with the options field property.

----

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 new link field introduced in Kirby 4 allows several different link types that each validate the entered link to the relevant URL format. It also includes a "Custom" link type for advanced use cases that don't fit any of the pre-defined link formats.

As the "Custom" link type is meant to be flexible, it also allows the javascript: URL scheme. In some use cases this can be intended, but it can also be misused by attackers to execute arbitrary JavaScript code when a user or visitor clicks on a link that is generated from the contents of the link field.

Patches

The problem has been patched in Kirby 4.1.1. Please update to this or a later version to fix the vulnerability.

In the patch release, we have updated the link field to hide the "Custom" link type by default and added a warning to our documentation that this link type should only be enabled if additional validation is performed or no protection against XSS attacks is needed.

Credits

Thanks to Natwara Archeepsamooth (@PlyNatwara) for responsibly informing us about the javascript: attack vector.

Withdrawn Advisory This advisory has been withdrawn because the vendor reports that some HTML formatting (such as with an H1 element) is allowed, but there is backend sanitization such that the reporter's mentioned "injecting malicious scripts" would not occur.

Original Advisory 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.

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, Kirby 3.7.5.4, Kirby 3.8.4.3, Kirby 3.9.8.1, Kirby 3.10.0.1, and Kirby 4.1.1. Please update to one of these or a later version 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.

A stored cross-site scripting (XSS) vulnerability in the Edit Content Layout module of Kirby CMS v4.1.0 allows attackers to execute arbitrary web scripts or HTML via a crafted payload injected into the Link field. NOTE: the vendor's position is that this issue did not affect any version of Kirby CMS. The only effect was on the trykirby.com demo site, which is not customer-controlled.

TL;DR

This vulnerability affects Kirby sites that use the URL field 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, Kirby 3.7.5.4, Kirby 3.8.4.3, Kirby 3.9.8.1, Kirby 3.10.0.1, and Kirby 4.1.1. Please update to one of these or a later version 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.

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 and Kirby 5.4.0. Please update to one of these or a later version to fix the vulnerability.

In all of the mentioned releases, Kirby has added 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 for responsibly reporting the identified issue.

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 and Kirby 5.4.0. Please update to one of these or a later version to fix the vulnerability.

In all of the mentioned releases, Kirby has 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.

TL;DR

This vulnerability affects all Kirby sites where users have the permission to create pages (pages.create permission is enabled) but not the permission to change the status of pages (pages.changeStatus permission is disabled). This can be due to configuration in the user blueprint(s), via options in the page blueprint(s) or via a combination of both settings.

Users' Kirby sites are not affected if their use case does not consider the creation of published pages a malicious action. The vulnerability can only be exploited by authenticated users.

----

Introduction

An authorization bypass allows authenticated users to perform actions they should not be allowed to perform based on their configured permissions, thereby causing a privilege escalation.

The effects of an authorization bypass can include unauthorized access to sensitive information as well as unauthorized changes to content or system information.

Impact

Kirby's user permissions control which user role is allowed to perform specific actions to content models in the CMS. These permissions are defined for each role in the user blueprint (site/blueprints/users/...). It is also possible to customize the permissions for each target model in the model blueprints (such as in site/blueprints/pages/...) using the options feature. The permissions and options together control the authorization of user actions.

For pages, Kirby provides the pages.create and pages.changeStatus permissions (among others). In affected releases, Kirby checked these permissions independently and only for the respective action. However the changeStatus permission didn't take effect on page creation.

New pages are created as drafts by default and need to be published by changing the page status of an existing page draft. This is ensured when the page is created via the Kirby Panel. However the REST API allows to override the isDraft flag when creating a new page. This allowed authenticated attackers with the pages.create permission to immediately create published pages, bypassing the normal editorial workflow.

Patches

The problem has been patched in Kirby 4.9.0 and Kirby 5.4.0. Please update to one of these or a later version to fix the vulnerability.

In all of the mentioned releases, Kirby has added a check to the page creation rules that ensures that users without the pages.changeStatus permission cannot create published pages, only page drafts.

Credits

Kirby thanks @offset for responsibly reporting the identified issue.

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 and Kirby 5.4.0. Please update to one of these or a later version to fix the vulnerability.

In all of the mentioned releases, 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.

Summary

Kirby CMS through version 5.1.4 allows an authenticated user with Editor permissions to cause a persistent Denial of Service (DoS) via a malformed image upload.

Details

The vulnerability is caused by improper validation of the return value of PHP's getimagesize() function. When a malformed file is uploaded with a valid image extension (e.g., .jpg), the function returns false instead of an expected array.

The application fails to handle this condition properly and proceeds with image processing, resulting in a fatal TypeError. This leads to persistent application crashes when the affected file is accessed.

Impact

- Persistent Denial of Service (DoS) - Affected pages return HTTP 500 errors - Requires manual removal of the malformed file to restore functionality - Exploitable by authenticated users with Editor permissions

TL;DR

This vulnerability affects all Kirby sites where user permissions are configured to prevent specific role(s) from performing write actions, specifically by disabling the update permission with the intent to prevent modifications to site content.

If developers haven't configured any user permissions that deviate from the default of allowing all actions, their site is not affected.

----

Introduction

Kirby allows to restrict the permissions of specific user roles. Users of that role can only perform permitted actions.

Permissions for updating content have already existed and could be configured for each model type, but were not enforced by Kirby's API backend code during operations to the changes version.

The changes version is the content version that contains unsaved changes of existing models (pages, users, files or the site).

Impact

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.

Patches

The problem has been patched in Kirby 5.2.2. Please update to this or a later version to fix the vulnerability.

In the mentioned release, we have added checks for the model update permissions that ensure that users without this permission cannot create, edit or discard the changes version of the respective model.

A future Kirby release will add separate edit and save permissions that will make it possible to control write actions to model content more granularly.

Credits

Thanks to Lukas Kleinschmidt (@lukaskleinschmidt) for responsibly reporting the identified issue.

Kirby is a flat-file CMS. In versions prior to 3.5.8.2, 3.6.6.2, 3.7.5.1, and 3.8.1, Kirby is subject to user enumeration due to Improper Restriction of Excessive Authentication Attempts. This vulnerability affects you only if you are using the code or password-reset auth method with the auth.methods option or if you have enabled the debug option in production. By using two or more IP addresses and multiple login attempts, valid user accounts will lock, but invalid accounts will not, leading to account enumeration. This issue has been patched in versions 3.5.8.2, 3.6.6.2, 3.7.5.1, and 3.8.1. If you cannot update immediately, you can work around the issue by setting the auth.methods option to password, which disables the code-based login and password reset forms.

TL;DR

This vulnerability affects all Kirby 5 sites that might have potential attackers in the group of authenticated Panel users or that allow external visitors to update page titles or usernames.

The attack requires user interaction by another Panel user and cannot be automated.

----

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 "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.

Patches

The problem has been patched in Kirby 5.1.4. Please update to this or a later version to fix the vulnerability.

In the patch release, we have added the required escaping code to signal to the browser the intent of displaying plain text instead of code in the places where the model titles are rendered.

TL;DR

This vulnerability affects all Kirby sites that use the snippet() helper or $kirby->snippet() method with a dynamic snippet name (such as a snippet name that depends on request or user data).

Sites that only use fixed calls to the snippet() helper/$kirby->snippet() method (i.e. calls with a simple string for the snippet name) are not affected.

----

Introduction

Kirby's snippet() helper and $kirby->snippet() method (in the following abbreviated to the snippet() helper) allow to load PHP snippet files that are normally stored in the site/snippets folder or registered by plugins through the snippets plugin extension.

If the snippet() helper is called with an arbitrary snippet name, Kirby first checks if a file with this name exists in the snippets root (which defaults to site/snippets).

This logic was vulnerable against path traversal attacks. By using special elements such as .. and / separators, attackers can escape outside of the restricted location to access files or directories that are elsewhere on the system. One of the most common special elements is the ../ sequence, which in most modern operating systems is interpreted as the parent directory of the current location.

Because Kirby's snippet() helper did not protect against path traversal, the provided snippet name could include special sequences that would cause Kirby to look outside of the configured snippets root and access arbitrary files.

Impact

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 snippets 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 snippet names, such as snippet('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.

Patches

The problem has been patched in Kirby 3.9.8.3, Kirby 3.10.1.2 and Kirby 4.7.1. Please update to one of these or a later version to fix the vulnerability.

In all of the mentioned releases, we have added a check for the snippet path that ensures that the resulting path is contained within the configured snippets root. Snippet paths that point outside of the snippets root will not be loaded.

Effects on site code

If you deliberately use path traversal in your projects, these uses will break after updating to one of the patched versions.

Examples of such uses include:

- Aliasing a template by loading another template with snippet('../templates/other-template'). Robust alternatives are to use require DIR . '/other-template.php' or to override the $page->template() method in the page model: php class AnotherPage extends Page { public function template(): Template { return $this->kirby()->template('other-template'); } } - Loading a snippet from a shared directory in a multisite setup. A robust alternative is to restructure the project so that all sites share a single snippets root that then branches off into subdirectories for each site. If you prefer to keep the original structure, you can use symbolic links (symlinks) in the file system to include the shared directory in the site-specific snippets roots.

Credits

Thanks to Bruno Meilick (@bnomei) for reporting the identified issue. Thanks to Bruno Meilick and Tobias Möritz (@tobimori) for their input on the effects on site code.

TL;DR

This vulnerability affects all Kirby setups that use PHP's built-in server. Such setups are commonly only used during local development.

Sites that use other server software (such as Apache, nginx or Caddy) are not affected.

----

Introduction

For use with PHP's built-in web server, Kirby provides a router.php file. The router delegates requests to static files to PHP so that assets and other static files in the document root can be accessed by the browser.

This logic was vulnerable against path traversal attacks. By using special elements such as .. and / separators, attackers can escape outside of the restricted location to access files or directories that are elsewhere on the system. One of the most common special elements is the ../ sequence, which in most modern operating systems is interpreted as the parent directory of the current location.

Impact

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.

Patches

The problem has been patched in Kirby 3.9.8.3, Kirby 3.10.1.2 and Kirby 4.7.1. Please update to one of these or a later version to fix the vulnerability.

In all of the mentioned releases, we have updated the router to check if existing static files are within the document root. Requests to files outside the document root are treated as page requests of the error page and will no longer allow to determine whether the file exists or not.

TL;DR

This vulnerability affects all Kirby sites that use the collection() helper or $kirby->collection() method with a dynamic collection name (such as a collection name that depends on request or user data).

Sites that only use fixed calls to the collection() helper/$kirby->collection() method (i.e. calls with a simple string for the collection name) are not affected.

----

Introduction

Kirby's collection() helper and $kirby->collection() method (in the following abbreviated to the collection() helper) allow to load PHP logic files that are normally stored in the site/collections folder or registered by plugins through the collections plugin extension.

If the collection() helper is called with an arbitrary collection name, Kirby first checks if a file with this name exists in the collections root (which defaults to site/collections).

This logic was vulnerable against path traversal attacks. By using special elements such as .. and / separators, attackers can escape outside of the restricted location to access files or directories that are elsewhere on the system. One of the most common special elements is the ../ sequence, which in most modern operating systems is interpreted as the parent directory of the current location.

Because Kirby's collection() helper did not protect against path traversal, the provided collection name could include special sequences that would cause Kirby to look outside of the configured collections root and access arbitrary files.

Impact

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.

Patches

The problem has been patched in Kirby 3.9.8.3, Kirby 3.10.1.2 and Kirby 4.7.1. Please update to one of these or a later version to fix the vulnerability.

In all of the mentioned releases, we have added a check for the collection path that ensures that the resulting path is contained within the configured collections root. Collection paths that point outside of the collections root will not be loaded.

An issue was discovered in Kirby 2.5.12. The application allows malicious HTTP requests to be sent in order to trick a user into adding web pages.

kirby is a content management system (CMS) that adapts to many different projects and helps you build your own ideal interface. Cross-site scripting (XSS) is a type of vulnerability that allows execution of 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. If bad actors gain access to your group of authenticated Panel users they can escalate their privileges via the Panel session of an admin user. Depending on your site, other JavaScript-powered attacks are possible. The multiselect field allows selection of 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 to store HTML code. The browser of the victim who visited a page with manipulated multiselect options in the Panel will then have rendered this malicious HTML code when the victim opened the autocomplete dropdown. Users are not affected by this vulnerability if you don't use the multiselect field or don't use it with options that can be manipulated by attackers. The problem has been patched in Kirby 3.5.8.1.

Kirby is a Content Management System. Prior to versions 3.5.8.2, 3.6.6.2, 3.7.5.1, and 3.8.1, a user enumeration 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. The problem has been patched in Kirby 3.5.8.2, Kirby 3.6.6.2, Kirby 3.7.5.1, and Kirby 3.8.1. In all of the mentioned releases, the maintainers have rewritten the affected code so that the delay is also inserted after the brute force limit is reached.

A vulnerability was found in bastianallgeier Kirby Webmentions Plugin and classified as problematic. Affected by this issue is some unknown functionality. The manipulation leads to injection. The attack may be launched remotely. The complexity of an attack is rather high. The exploitation is known to be difficult. The patch is identified as 55bedea78ae9af916a9a41497bd9996417851502. It is recommended to apply a patch to fix this issue. VDB-218894 is the identifier assigned to this vulnerability.

Kirby is an open source file structured CMS. In affected versions Kirby's blocks field stores structured data for each block. This data is then used in block snippets to convert the blocks to HTML for use in your templates. We recommend to escape HTML special characters to protect against cross-site scripting (XSS) attacks. The default snippet for the image block unfortunately did not use our escaping helper. This made it possible to include malicious HTML code in the source, alt and link fields of the image block, which 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. Attackers must be in your group of authenticated Panel users in order to exploit this weakness. Users who do not make use of the blocks field are not affected. This issue has been patched in Kirby version 3.5.8 by escaping special HTML characters in the output from the default image block snippet. Please update to this or a later version to fix the vulnerability.

Kirby is an open source file structured CMS ### Impact Kirby's writer field stores its formatted content as HTML code. Unlike with other field types, it is not possible to escape HTML special characters against cross-site scripting (XSS) attacks, otherwise the formatting would be lost. If the user is logged in to the Panel, a harmful script can for example trigger requests to Kirby's API with the permissions of the victim. Because the writer field did not securely sanitize its contents on save, it was possible 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. Attackers must be in your group of authenticated Panel users in order to exploit this weakness. Users who do not make use of the writer field are not affected. This issue has been patched in Kirby 3.5.8 by sanitizing all writer field contents on the backend whenever the content is modified via Kirby's API. Please update to this or a later version to fix the vulnerability.

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 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.

----

Introduction

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 or browser even if the logged in user has since changed their password.

Impact

Kirby did not invalidate old user sessions after the user password was 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.

Patches

The problem has been patched in Kirby 3.5.8.3, Kirby 3.6.6.3, Kirby 3.7.5.2, Kirby 3.8.4.1 and Kirby 3.9.6. Please update to one of these or a later version to fix the vulnerability.

In all of the mentioned releases, we have updated the authentication implementation to keep track of the last time the password was changed. If a new password was set 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.

Credits

Thanks to Shankar Acharya (@5hank4r) for responsibly reporting the identified issue.

TL;DR

This vulnerability 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.

----

Introduction

Denial of service (DoS) is a type of attack in which an attacker floods a service with the intention to limit performance or availability for legitimate users of the service.

In the variation described in this advisory (a so called application layer denial of service attack), it is performed by causing a computationally expensive task to be run on the server. This may then cause a performance bottleneck.

Impact

Kirby's authentication endpoint did 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.

Patches

The problem has been patched in Kirby 3.5.8.3, Kirby 3.6.6.3, Kirby 3.7.5.2, Kirby 3.8.4.1 and Kirby 3.9.6. Please update to one of these or a later version to fix the vulnerability.

In all of the mentioned releases, we 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.

Credits

Thanks to Shankar Acharya (@5hank4r) for responsibly reporting the identified issue.

TL;DR

This vulnerability 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).

Your Kirby sites are not affected if they don't allow write access for untrusted users or visitors.

----

Introduction

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.

Impact

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 during the read process the BOM was removed, turning the malicious line into a valid separator. This 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.

Patches

The problem has been patched in Kirby 3.5.8.3, Kirby 3.6.6.3, Kirby 3.7.5.2, Kirby 3.8.4.1 and Kirby 3.9.6. Please update to one of these or a later version to fix the vulnerability.

In all of the mentioned releases, we 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.

Credits

Thanks to Patrick Falb (@dapatrese) at FORMER 03 for responsibly reporting the identified issue.