TL;DR

This vulnerability affects all Kirby sites that are deployed to a server that allows requests for URLs with encoded slashes (%2f), such as nginx, PHP's built-in server or Apache setups that have the option AllowEncodedSlashes enabled. It was possible to create and access thumbnails from media files in arbitrary accessible directories on the server that have a valid thumbnail configuration (JSON job file). It was also possible to detect the presence of files with the .json file extension anywhere on the server. This vulnerability is of high severity for affected sites. Server setups using Apache's default configuration or other servers that have been hardened against encoded slashes in URLs are not affected.

----

Introduction

A path traversal (also known as directory traversal) vulnerability occurs when untrusted input is used to build a filesystem path without properly confining the result to an intended base directory. By injecting sequences such as ../, an attacker can escape that directory and reach files elsewhere on the server.

Affected components

Kirby's media handler processes requests for files in the media directory that have not been generated yet. It parses the provided path and finds the correct file or asset from which to generate a thumbnail. Each thumbnail needs to have a prepared job file (a metadata file with file extension .json) in order to allow the media handler to generate it. Each parent (such as a page) has its own media directory, which in turn contains the individual files. Kirby's media handler searches for the file within the parent's media directory.

Impact

In affected releases, Kirby did not prevent path traversal in the filenames that were searched within the parent directory. In affected server setups where the attacker can provide encoded slashes (%2f) in the request, Kirby allowed the request to traverse away from the parent's media directory. Because the response differs between existing and non-existing thumbnail configurations, attackers were able to tell whether an arbitrary JSON file exists on the server (addressed by a relative path from the media directory of an arbitrary existing parent, including a relative path that points outside of the site's index root). For existing files with the file extension .json and a valid filename key (resulting in a valid job file), it was possible to generate thumbnails of the referenced media files, deleting the job file in the process. Patches

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

In all of the mentioned releases, Kirby\Cms\Media::thumb() now rejects any filename that contains path information (anything other than a plain filename) before it is appended to the validated root. We have also hardened the file::version component to block paths that contain the ../ sequence.

Credits

Thanks to Jorge González Milla (@Pig-Tail) for responsibly reporting the identified issue.

TL;DR

This vulnerability affects all Kirby sites that are deployed in a way that their index root on the server is next to a second directory that is read-accessible to PHP and shares the same name prefix (such as the site with the index root /var/www/site being next to /var/www/site2).

It was possible to create and access thumbnails from media files within such sibling directories that have a valid thumbnail configuration (JSON job file). This can affect staging sites, site backups or other internal sites.

----

Introduction

A path traversal (also known as directory traversal) vulnerability occurs when untrusted input is used to build a filesystem path without properly confining the result to an intended base directory. By injecting sequences such as ../, an attacker can escape that directory and reach files elsewhere on the server.

Affected components

Kirby's media handler processes requests for files in the media directory that have not been generated yet. It parses the provided path and finds the correct file or asset to generate a thumbnail of. Each thumbnail needs to have a prepared job file (a metadata file with file extension .json) in order to allow the media handler to generate a thumbnail.

The media handler uses filesystem containment checks in several places that are supposed to prevent breakout of the media and index roots of the site.

Impact

In affected releases, the containment checks were incomplete and did not cover the case of a sibling directory next to the containment directory that starts with the same prefix. E.g. a directory site2 passed the containment check of directory site. This allowed attackers to access media files with prepared job files that are stored within such sibling directories of the site's index root, opening the potential for information leaks from sensitive files stored within them, and deleting the job file in the process.

Patches

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

In all of the mentioned releases, we have hardened the containment helpers Kirby\Filesystem\Dir::realpath() and Kirby\Filesystem\F::realpath() to require either an exact match or a DIRECTORYSEPARATOR boundary, so that a sibling path sharing the same name prefix can no longer pass the check. This prevents access to files outside the index root of the active site. We have also hardened the Asset class to block paths that contain the ../ sequence.

Credits

Thanks to @0x1saac for responsibly reporting the identified issue.

TL;DR

This vulnerability affects all Kirby sites where users of a particular role have access to the REST API (access.panel permission is enabled) but no permission to upload any kind of file (files.create, files.replace and user/users.update permissions are all disabled).

It was possible to fill up the temporary directory for chunked uploads with unfinished chunks even as a user without any upload permission.

This vulnerability is of high severity for affected sites.

Your Kirby sites are not affected if you intend all users of your site to be able to upload files. The vulnerability can only be exploited by authenticated users. It was not possible to bypass the actual permission checks for any files that end up in the content or site/accounts folders.

----

Introduction

Missing authorization allows authenticated users to perform actions they are not intended to have access to.

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

Affected components

Kirby's REST API provides routes to upload files, specifically to create content files, replace existing content files and to create and replace user avatars.

Each upload route takes either full file upload requests or chunked upload requests that can be continued in subsequent requests. During a chunked upload, the incomplete state of the uploaded file is stored in a temporary directory until the last chunk completes the file. At this time, the final permission and business logic checks are performed before the complete file is moved to its final destination.

Impact

In affected releases, the chunk upload handler did not check for the user's file upload permissions before storing incomplete chunk data in the temporary directory.

This allowed attackers without upload permissions to upload multiple large files in chunks. If the final chunk was never provided, Kirby would keep the incomplete files for 24 hours. This could cause attacker-controlled storage consumption until the temporary files were automatically cleaned up or manually removed, potentially preventing other users from uploading files, or site logic from storing data.

Patches

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

In all of the mentioned releases, we have added preflight checks to the upload chunk processor that verify the relevant system permission before storing the chunk data in the temporary directory.

Credits

Thanks to @alcls01111 for responsibly reporting the identified issue.

TL;DR

This vulnerability affects all Kirby sites that have not disabled the REST API with the 'api' => false option.

It was possible to trigger a PHP error in the API backend that would expose the full filesystem path of the Kirby installation on the server. This could be used to guess the default content.salt or prepare specialized attacks.

----

Introduction

An information exposure occurs when system data or debugging information leaves the program through an output stream or logging function that makes it accessible to unauthorized parties. Using other weaknesses, an attacker could cause errors to occur; the response to these errors can reveal detailed system information, along with other impacts. An attacker can use messages that reveal technologies, operating systems, and product versions to tune the attack against known vulnerabilities in these technologies. A product may use diagnostic methods that provide significant implementation details such as stack traces as part of its error handling mechanism.

Affected components

Kirby's REST API at /api returns JSON data for each request. If an error occurs during processing of the request, a special error handler converts this error to JSON data that API frontends can handle.

The returned data for errors depends on the debugging mode. If the debug option is enabled, the JSON data contains fields for the path and line of the affected file, the internal exception class and the API route that caused the error. This data is omitted from error responses in production (when the debug option is disabled).

Impact

Some internal errors may contain sensitive information in the error message itself. This is often the case with PHP errors.

In affected releases, the REST API error handler did not sanitize error messages for sensitive information.

This exposed system information like the full source path to external API users, including users without authentication. This could be used to guess the default content.salt or prepare specialized attacks.

Patches

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

In all of the mentioned releases, Kirby has hardened the API error handler to only expose full error messages for exceptions in the Kirby\Exception namespace. All other errors are only exposed in debug mode (with disguised paths, keeping only the paths relative to the Kirby installation). Outside of debug mode, general exceptions and PHP errors are replaced with a generic error message.

Credits

Thanks to Peter Levashov (@petersevera) for responsibly reporting the identified issue.

kirby-modules through 5.5.7, fixed in commit 315417e, contains an information disclosure vulnerability that allows any authenticated Kirby Panel user to retrieve the full plaintext commercial license key by sending a GET request to the modules/activate dialog endpoint. The plugin's activate dialog handler in lib/areas.php returns the complete key via ModulesLicense::readKey() without performing an administrator check, as the dialog is gated only by the access.system permission which defaults to true for all non-admin roles, enabling attackers to use the disclosed key to activate the plugin on arbitrary third-party installations.

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

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

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.