getkirby/cms

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

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

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

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

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

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 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 where users of a particular role have no permission to access pages (pages.access permission is disabled). This can be due to configuration in the user blueprint(s), options in the model blueprint(s), or a combination of both settings.

It was possible to retrieve page information (including full content and metadata) for arbitrary pages via the /api/site/find route without being authorized to access the respective pages.

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 access all pages of the site. The vulnerability can only be exploited by authenticated users that know or guess the IDs or UUIDs of pages. Write actions as well as access to draft pages are not affected by this vulnerability.

Introduction

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

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

Affected components

The /api/site/find route allows callers to request model data for a collection of user-selected pages. This model data includes structural metadata about the page itself and its children, siblings, and files and can also be extended via a query parameter to return full page content and additional metadata. The pages to return can be queried by a list of page IDs and/or UUIDs. Draft pages are excluded from this route as it only supports querying published pages.

Impact

In affected releases, Kirby did not check whether the queried pages were accessible to the currently authenticated user.

This can lead to disclosure of sensitive information contained in inaccessible pages, including the confirmation of the existence of individual pages as well as disclosure of sensitive content fields stored in the pages. Linked children, siblings, or files were not affected by this vulnerability as they were already properly filtered by the appropriate pages.list and files.list permissions.

Because the /api/site/find route is read-only, the vulnerability does not allow malicious write access.

Patches

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

In all of the mentioned releases, we added a filter ensuring that the /api/site/find route only returns pages that are accessible to the current user.

Credits

Thanks to Rizky Muhammad (@EvidentObscurity) for responsibly reporting the identified issue.

TL;DR

This vulnerability affects Kirby 5 sites that have the content.fileRedirects option enabled (set to true or a custom closure) as well as all Kirby 4 sites that haven't explicitly disabled this option.

It was possible to access clean file URLs of top-level drafts (e.g. /about-us/team.jpg) without providing authentication, without being authorized to access the top-level draft page, and without providing a valid preview token.

Sites on Kirby 5 using the default configuration are not affected by this vulnerability (the content.fileRedirects option is disabled by default since Kirby 5.0.0). It was also not possible to maliciously access clean file URLs for files stored in page drafts that are not on the top-level (such as /blog/article/resource.pdf).

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

Clean file redirects allow visitors to access files stored in the content folder via natural URLs such as /about-us/team.jpg or /blog/article/resource.pdf. Kirby detects such requests and redirects them to the actual physical file URLs in the media folder.

Kirby 4.8.0 introduced the content.fileRedirects option that allowed disabling this behavior to protect against third-party access to original source files. Kirby 5.0.0 then made the secure behavior (disabled option) the default. It is also possible to set the option to a closure to dynamically control access for each individual file.

Files can be stored in pages. Pages can exist as drafts. In this draft state, the page preview is only accessible to users who are authenticated and authorized by the pages.access permission or to visitors who have received the direct preview URL with a valid preview token.

Impact

In affected releases, the clean file redirects didn't take access logic for drafts into account. When a file stored in a draft page was accessed via its clean file URL, Kirby immediately redirected to the physical media URL without first checking whether the draft page was accessible to the user or visitor. This only affected top-level drafts (direct children of the site) because clean file URLs currently don't work for drafts that are nested under another page.

The unauthorized clean file URL redirects for files in top-level drafts can lead to disclosure of sensitive information or data, e.g., ahead of the launch of a new product or post.

A successful attack requires knowledge of the full path to the draft page and file, and therefore requires knowing the full clean file URL.

Patches

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

In all of the mentioned releases, we added an authorization check to the route that redirects clean file URLs of drafts. This route now performs the same checks as the draft preview route, i.e., it only performs the redirect if a user is logged in and has the pages.access permission on the draft, or if a valid preview token was provided in the request URL.

Credits

Thanks to @adamyordan for responsibly reporting the identified issue.

TL;DR

This vulnerability affects Kirby sites that have no configured user accounts and are running on publicly accessible servers behind a reverse proxy that sets the Forwarded: for=..., X-Client-IP, or X-Real-IP request header.

It was possible to install the Panel (= create the first admin user) in these setups even from remote IP addresses.

This vulnerability is of critical severity for affected sites.

Your site is not affected if any of the following apply:

• An admin account has already been configured
• The Panel and API are disabled
• The site is not running behind a reverse proxy
• The reverse proxy sets the X-Forwarded-For or Client-IP header instead of the affected ones.

Introduction

External Initialization is a type of vulnerability that allows attackers to initialize a system or configuration value without authentication.

This can give untrusted actors access to the system or let them control its behavior.

Affected components

The Kirby Panel and REST API are authenticated by local user accounts. If a Kirby installation does not yet have any users, it first needs to be installed. During the installation process, an initial admin user account is created.

To protect against external initialization attacks that would allow untrusted actors to create an admin user for the Kirby installation, Kirby already checked whether the current request came from a local IP address. This allows installing the Panel in local development setups. Installation on remote servers was only supposed to be possible when the panel.install configuration option was enabled.

The isLocal check takes all relevant request headers into account and treats a request as non-local as soon as any checked request header contains an external IP address.

Impact

In affected releases, the isLocal check for the installation logic did not properly take the Forwarded: for=... header into account. This header is set by modern reverse proxy servers. It also did not take into account the X-Client-IP or X-Real-IP headers, which are set by some custom reverse proxy setups.

This caused Kirby to falsely assume that an installation request was local and allowed creating an admin account even though the reverse proxy forwarded the request from an external IP address.

Reverse proxies setting the X-Forwarded-For or Client-IP headers were not affected. These headers were already properly checked for external IP addresses.

Patches

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

In all of the mentioned releases, we fixed the isLocal check to also properly take Forwarded: for=..., X-Client-IP and X-Real-IP request headers into account.

Workarounds

Sites on older Kirby versions (Kirby 3 starting at 3.7.0) can be protected with one of the following workarounds:

• Perform the Panel installation yourself by creating an initial admin account. As soon as one or more accounts are present, the vulnerable installation code is no longer active.
• If you don't need the Panel, disable the REST API with the 'api' => false option in config.php.

Credits

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

TL;DR

This vulnerability affects Kirby sites and plugins that use the writer or list fields or that use $dom->sanitize(), Sane::sanitize(), Sane\Html::sanitize(), Sane\Svg::sanitize(), Sane\Xml::sanitize(), Sane::sanitizeFile() or $file->sanitizeContents() with untrusted input.

It was possible to inject malicious markup as children of an unknown HTML/XML tag, which would then be passed through Dom::sanitize() without being correctly sanitized according to the provided sanitization rules, causing a cross-site scripting (XSS) risk.

This vulnerability is of high severity for affected sites.

The default file upload protection is not affected, so sites that only validate uploaded files are not exposed to this vulnerability. The vulnerability can only be exploited by authenticated users.

Introduction

Cross-site scripting (XSS) is a type of vulnerability that allows executing any kind of JavaScript code inside the site frontend or Panel session of the same or other users. In the Panel, a harmful script can, for example, trigger requests to Kirby's API with the permissions of the victim.

In a stored XSS attack, the malicious payload is saved into the content data and has the potential to affect other users or site visitors.

Such vulnerabilities are critical if 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.

A specific class of stored XSS is auto-firing, meaning the maliciously injected JavaScript code is executed by the browser when the page loads without the victim having to perform a specific action.

Affected components

The Dom::sanitize() method allows removing unwanted or malicious elements or attributes from DOM documents (which includes HTML, SVG or arbitrary XML data). Sanitized content is supposed to be protected against cross-site scripting (XSS) attacks by removing their impact from untrusted content input.

Dom::sanitize() internally checks all nodes and attributes of the DOM document. It removes nodes, attributes, processing instructions, doctypes and namespaces that are not allowed according to the provided configuration. Nodes with tags that have been explicitly blocklisted are removed together with their children. Nodes with explicitly allowlisted tags are kept. If a tag is neither allowlisted nor blocklisted, nodes with that tag are unwrapped by Dom::unwrap() (meaning the children are kept).

Dom::sanitize() is used in the following components:

• The writer field sanitizes all entered content on the backend before it is saved to the content file.
• The list field performs the same sanitization as the writer field since Kirby 5.4.1 (and in backported versions since Kirby 4.9.1).
• The Kirby\Sane class package includes higher-level classes Sane\Html, Sane\Svg and Sane\Xml that all rely on DOM sanitization.
• These classes are in turn also used by Sane::sanitizeFile() and $file->sanitizeContents().
• Any of the mentioned methods could also be used in site or plugin code, for example in a file.create:before hook that cleans uploaded SVG/HTML files.

Only the sanitization path (returning a cleaned document) is affected. The validation path is not affected by this vulnerability. Kirby's default upload protection performs validation, so malicious SVG or HTML uploads continue to be rejected.

Impact

In affected releases, Dom::sanitize() did not sanitize nodes that had been unwrapped from their parent node. The affected child nodes would be copied into the resulting sanitized document without being sanitized.

An authenticated Panel user who can edit a writer or list field can store markup that survives sanitization and executes as JavaScript when the content is rendered, both in the Panel and on the site frontend. This allows a lower-privileged editor to run scripts in the context of higher-privileged users (for example admins) who view the content ("stored XSS"). Where a plugin or custom code cleans uploaded SVG/HTML with the Sane API, the same flaw leaves active content in the stored file, which executes when the file is served.

Patches

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

In all of the mentioned releases, Dom::unwrap() now moves the allowed children to the parent instead of cloning them, so the exact nodes remain in the document and are covered by the sanitization pass.

Note that content that was passed through the sanitizer and stored as field content before the patch may contain malicious content that was not properly sanitized due to the vulnerable code. If you cannot rule out attackers under the authenticated users of a security-critical site, we advise reviewing the content for possible attacks or to re-sanitize all content of affected fields.

Credits

Thanks to Shafiq Aiman (@shafiqaimanx) for responsibly reporting the identified issue.

TL;DR

This vulnerability affects Kirby sites and plugins that use the Kirby\Http\Remote class (including Remote::request(), Remote::get(), Remote::post(), and similar helpers) to send outgoing HTTP requests and that pass untrusted, user-controlled data into the headers option of such a request.

By including newline characters in the value of the header, it was possible to inject a separate, independent header that was not intended to be set.

A successful attack requires that an application or plugin forwards attacker-influenced input into a request header value. Sites that only send static, developer-defined headers are not affected. The attack does not target Panel users or site visitors directly; it targets the remote service that Kirby connects to.

In Kirby's default configuration, the Remote class is not exposed to untrusted input, so a default installation is not affected. The vulnerability becomes relevant for custom code, plugins, or integrations that build request headers from user input.

Introduction

HTTP header injection (also known as CRLF injection) is a type of vulnerability that allows an attacker to insert additional, attacker-controlled HTTP headers into a request or response. HTTP headers are separated by carriage-return and line-feed characters (\r\n). If untrusted data containing these characters is placed into a header value without sanitization, an attacker can terminate the intended header early and append headers of their own.

For outgoing requests, this means an attacker who controls part of a header value can add or override headers that the application did not intend to send. Depending on the remote service, this can be used to override security-relevant headers (such as Authorization, Host, or Cookie), to smuggle requests, or to poison caches on the upstream system.

Such vulnerabilities are relevant if untrusted input can reach the header values of an outgoing request – for example, a user-configurable API token, a forwarded tracking identifier, or any other value that originates from a request, form field, or content file.

Affected components

The Kirby\Http\Remote class is used throughout Kirby and by plugins to perform outgoing HTTP requests. Its headers option allows callers to define the headers sent with the request.

As the vulnerability is in the way Remote assembles these headers, it affects all code paths that send a Remote request whose header values contain untrusted data. The Kirby core itself has not passed untrusted data in that way, but plugins or custom code might have used the class in such a way.

Impact

In affected releases, header values passed to Remote were handed to the cURL request library without removing newline characters:

The headers option accepted arbitrary strings as header values and forwarded them to the underlying cURL request unchanged. A value containing \r\n was written verbatim to the socket and therefore split into several header lines on the wire.

For example, a single X-Foo header value of "Bar\r\nX-Injected: pwned" produced two separate headers in the outgoing request:

X-Foo: Bar
X-Injected: pwned

The receiving server parsed X-Injected: pwned as its own header. In the same way, an attacker could override a header that the application set earlier in the same request (for example, replacing a legitimate Authorization header).

The vulnerability allows attackers to inject or override HTTP headers in outgoing requests, provided the affected application or plugin includes attacker-controlled data in a header value.

Patches

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

In all of the mentioned releases, we now strip carriage-return and line-feed characters from header values before they are passed to the underlying request, preventing additional headers from being injected.