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.