Skip to content

Releases: getkirby/kirby

5.5.0

Choose a tag to compare

@bastianallgeier bastianallgeier released this 02 Jul 11:09
79b15cf

🎉 Features

Local development licenses

A Kirby site can now be activated as development site when you confirm to comply with the license terms for free development licenses. When the site is not set up locally, Kirby will regularly check that your development site is not publicly accessible. #7832

Screenshot 2026-07-01 at 16 02 33

Frontmatter Data Handler

New Frontmatter Data handler, which can be used to import or export frontmatter into Kirby. #8019

Decoding

use Kirby\Data\Frontmatter;

$md = <<<MD
---
title: My new article
date: '2026-03-12'
---
# Hello world

This is my brand new article written in **Frontmatter/Markdown**
MD;

$result = Frontmatter::decode($md);

// [
//  'title' => 'My new article',
//  'date' => '2026-03-12',
//  'text' => '# Hello world ...'
// ]

Encoding

use Kirby\Data\Frontmatter;

$result = Frontmatter::encode([
  'title' => 'My new article',
  'date' => '2026-03-12',
  'text' => '# Hello world …'
]);

// ---
// title: My new article
// date: 2026-03-12
// ---
// # Hello world …

New translations

  • Japanese (thanks to Kosuke Okahara)
  • Ukranian

✨ Enhancements

  • SmartyPants is directly using UTF-8 characters instead of HTML entities
  • A page/site/user/file will now automatically be unlocked, as soon as the editor leaves the view or closes the tab/window. This will make sure that content-editing is not unnecessarily blocked for other editors. #7975
    • New Kirby\Content\Version::unlock() method
    • New panel.content.unlock() method
    • New /api/(:all)/changes/unlock route
  • License dialog: Show registered domain and link to license terms #7832
  • You can now use this.$helper.string.sanitizeHTML() in the Panel to create a clean HTML string with configurable marks and nodes. By default, the sanitizer will only keep inline marks (bold, code, italic, link, strike, sub, sup, underline) #7922
    this.$helper.string.sanitizeHTML('<p><marquee><strong onclick="alert(\'boo\')">Foo</strong></marquee></p>')
    // returns: <strong>Foo</strong>
    To set custom writer marks and nodes, you can pass an options object:
    this.$helper.string.sanitizeHTML(unsanitizedHTML, {
      marks: ["bold"],
      nodes: ["doc", "praagraph", "text")]
    });
  • It's now possible to define any extension directly in your config, to be able to set site-specific extensions without creating a helper plugin. #8005
    // /site/config/config.php
    
    return [
      'extensions' => [
        'pageModels' => [
          // ...
        ],
        'blueprints' => [
          // ...
        ]
      ]
    ];
  • Link field: reduced the amount of backend request fired directly when mounted (thx @tobimori) #8072
  • Added some missing common/modern extensions to Kirby\Filesystem\F::$types and Kirby\Filesystem\Mime::$types. #8134
  • New Kirby\Toolkit\A::flip() method #8132
  • Increased length of randomly generated chunk IDs for chunked uploads to reduce risk of filename collisions #8182
  • New Kirby\Filesystem\F::update($file, $callback) method that reads and updates a file under lock #8187
  • Improved error handling for block snippet errors rendered via Kirby\Cms\Block::toHtml() by logging suppressed errors and escalating exceptions in debug mode #8085.
  • Added a translatable default placeholder for the tags field input #6114

🏎️ Performance

  • Improved performance of several system methods:
    • Kirby\Filesystem\Dir::size() #8131
    • Kirby\Filesystem\Mime::fromSvg() #8130
    • Kirby\Filesystem\Mime::toExtension() and Kirby\Filesystem\Mime::toExtensions() #8133
    • Kirby\Toolkit\Controller #8143
    • Kirby\Toolkit\Html::attr() and Kirby|Toolkit\Xml::encode() #8144
    • Kirby\Toolkit\Str::similarity(), Kirby\Toolkit\Str::startsWith(), Kirby\Toolkit\Str::endsWith(), Kirby\Toolkit\Str::encode(), Kirby\Toolkit\Str::ascii() #8138 #8147 #8145 #8158
    • Excluded keys lookup set in Kirby\Toolkit\A::without() #8146

🐛 Bug fixes

  • Structure field previews: fields with HTML content (e.g. list, writer) do not expand the table with all their content anymore #7918
  • Fixed URL validation for URLs with multiple hyphens #7942
  • Redis cache driver: Fixed flushing all databases even when using a prefix. Now only the Reds database for the cache with its prefix gets flushed. #8148
  • Fixed minWords/maxWords validators for non-single whitespace #8141
  • Handle Dir::remove() with atomic rename #6266
  • panel.request.body(null) does not send "null" to the backend as the request body anymore #8016
  • Unset request headers aren't sent as "false" to the backend anymore but instead omitted from the request. #8016
  • Fixed handling of partial step config arrays in Kirby\Toolkit\Date
  • Kirby\Toolkit\LayzValue: fixed passing variadic arguments #8139
  • Kirby\Toolkit\A::implode(): preserve falsy values when imploding array #8140
  • Fixed fractional support for Kirby\Toolkit|Str::toBytes() #8159
  • Blocks field: Fixed batch delete #8206
  • Panel system view: The warning for the default cookie key is no longer displayed if a custom cookie key was set via the cookie.key option
  • Panel: Fixed failing to load when a stricter Content-Security-Policy with nonce-based script-src is used. #8208
  • I18n::template(): Prevent TypeError when $replace is null #8199
  • Kirby queries: Fixed tokenizer position desync on multibyte characters (@thx @LaurentTacco) #8203
  • Fixed a content lock deadlock in multilingual setups where saving a secondary language while another user holds the lock on the primary language would cause both users to see the page as locked by the other. #8099
  • Fixed file sorting when a secondary language is active #8212
  • Fixed Cmd/Ctrl+S in textarea toolbar dialogs inserting [object Object] instead of the formatted link/email text. #7934
  • Disabled unselected model picker options once the field’s max limit is reached #8232
  • Localize license hub link #8239

☠️ Deprecated

  • Using arbitrary custom permissions without registering them first via the permissions extension has been deprecated. Those will be ignored in a future release, so make sure to define your custom permissions via the permissions extension. #8070
  • Kirby\Text\KirbyTag::option() and Kirby\Text\KirbyTag::$options: Use $tag->kirby()->option() instead. #8196
  • Kirby\Text\KirbyTags::parse(): $options parameter. Use new $debug parameter instead. #8196

♻️ Refactored

  • New Kirby\Cms\LicenseStatus::Acknowledged and Kirby\Cms\LicenseType::Free cases #7832
  • $helper.string.hasEmoji(): simplified regular expression #7966
  • Started refactoring some of our JavaScript code as TypeScript for increased type-safety #7973
  • New RedirectError error class with support in panel.error() #8016
  • Refactored Permissions (thanks to @lukaskleinschmidt) #8004
    • Renamed Permissions::$actions property to $defaults; added separate protected array $actions populated by the constructor
    • Replaced 6 old methods (Permissions::setAll, Permissions::setCategory, Permissions::setCategories, Permissions::setAction, Permissions::hasAction, Permissions::hasCategory) with 4 cleaner ones: Permissions::normalize(), Permissions::expand(), Permissions::get(), Permissions::has()
    • Permissions::normalize() and Permissions::expand() handle all four input shapes: null, bool, ['cat' => bool], ['cat' => ['action' => bool]], including wildcard at both levels.
    • Permissions::for() now deprecates $category = null via Helpers::deprecated() and throws LogicException if a stored value is somehow not a bool
    • Slightly refactored the Blueprint class: array_fill_keys(array_keys($defaults), false) instead of array_map(fn () => false, $defaults).
  • Ensure not wrapping <div> tags with <span> tags in <k-input> #8018
  • New Kirby\Template\Snippet::hasSlots() method #8178
  • Guard Slots in Snippets from being double-opened #8179
  • New $debug parameter in Kirby\Text\KirbyTags::parse() #8196
  • Clarify Html::rel() use #8142

🚨 Breaking changes

  • Kirby\Cms\Block::toHtml() now throws block snippet exceptions in debug mode instead of returning an inline Block error message. While this is technically a breaking change, we see this as a debugging enhancement which can clearly go into a minor release without negative impact for real-world projects.

🧹 Housekeeping

  • Extended our contributing guidelines #7949
  • Use cpx for pinned composer dependencies shared between local dev and CI
  • Replace jsdom with happy-dom for frontend unit tests #7971
  • New...
Read more

5.4.4

Choose a tag to compare

@bastianallgeier bastianallgeier released this 17 Jun 10:28
3f96d3b

Note

This release is part of our monthly security release series. Find out more about those releases and their background on our website: https://getkirby.com/buzz/security-update

🚨 Security

🛎️ Recommendation to secure your content salt and cookie key values

Kirby internally relies on the following values:

  • The content.salt option is used to generate secure preview and media URLs that should not be guessable by external visitors.
  • The Kirby\Http\Cookie::$key property, to sign (or authenticate) cookie values to prevent easy tampering with cookie values that have been set from the backend.

We recommend to set the content.salt and Kirby\Http\Cookie::$key values to long random strings for all of your sites.

We have updated the security guide with a section on this topic and added warnings to the Panel system view if Kirby detects the unchanged defaults.

Thanks to @adrgs and Peter Levashov (@petersevera) for their responsible disclosure and suggestion.


External Initialization of the Panel on reverse proxy setups with the Forwarded, X-Client-IP or X-Real-IP header

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.

Advisory Details:

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


Cross-site scripting (XSS) from incomplete HTML/XML sanitization in Dom::sanitize()

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.

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


Self cross-site scripting (self-XSS) in the writer field

This vulnerability affects Kirby sites that use the writer field in any blueprint.

It was possible to include a scripting link as the target of a link (or email link). This link target would then be clickable by the user who entered it.

A successful attack commonly requires knowledge of the content structure by the attacker as well as social engineering of a user with access to the Panel. The attack cannot be automated.

In Kirby's default configuration, the vulnerability is limited to self-XSS and cannot directly affect other users or visitors of the site. Panel plugins that are directly using the <k-writer> component may also be affected by stored XSS if they don't sanitize the resulting HTML before saving it to the content.

This vulnerability is of high severity for affected sites.


pages.access permission is not checked in the site/find REST API route

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.

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


Request header injection in Http\Remote

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.


Access to files of top-level drafts is not protected by permissions

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

Thanks to @adamyordan for responsibly reporting the identified issue.


pages.access permission is not checked in the pages picker for parent pages

This vulnerability affects all Kirby sites that use the pages field and 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 confirm the existence of arbitrary pages and to retrieve the value of the title field of the pages found.

The vulnerability can only be exploited by authenticated users. Write actions are not affected by this vulnerability.


🚨 Security fixes

  • The link and email marks of the writer field are now protected against self-cross site scripting (self-XSS) from inserted scripting links
  • The page picker in the pages field now consistently checks the pages.access permission for the provided parent page
  • Results of the site/find API route are now filtered to only return pages that are accessible to the current user.
  • Files on draft pages are no longer exposed through clean file URLs when content.fileRedirects is enabled.
  • Kirby no longer allows to install the Panel with the first user account if a Forwarded: for=..., X-Client-IP or X-Real-IP request header with external IP address was provided by a reverse proxy.
  • Show warnings in the system view when the content.salt option and Cookie::$key default values have not been changed.
image

✨ Enhancements

  • Harden TO...
Read more

4.9.4

Choose a tag to compare

@bastianallgeier bastianallgeier released this 17 Jun 10:28

Note

This release is part of our monthly security release series. Find out more about those releases and their background on our website: https://getkirby.com/buzz/security-update

🚨 Security

This is a backport of our security release for Kirby 5. For all details and vulnerabilities see: https://github.com/getkirby/kirby/releases/tag/5.4.4

We recommend all users upgrade to Kirby 5. If an upgrade is not possible, this security release is the alternative solution.

5.4.3

Choose a tag to compare

@bastianallgeier bastianallgeier released this 27 May 11:26
649acf7

🐛 Bug fixes

  • Throw exceptions for UUID cache misses when content.uuid.index = false is set only in debug mode #8150

🚨 Security

  • Updated PHP and JS dependencies

4.9.3

Choose a tag to compare

@bastianallgeier bastianallgeier released this 27 May 11:20

🚨 Security

  • Updated PHP and JS dependencies

5.4.2

Choose a tag to compare

@bastianallgeier bastianallgeier released this 20 May 15:01
591dd36

🚨 Security

After our 5.4.1 release yesterday, the symfony/yaml package had a security release today. This is a patched version with the updated yaml dependency.

4.9.2

Choose a tag to compare

@bastianallgeier bastianallgeier released this 20 May 14:52

🚨 Security

After our 4.9.1 release yesterday, the symfony/yaml package had a security release today. This is a patched version with the updated yaml dependency.

5.4.1

Choose a tag to compare

@bastianallgeier bastianallgeier released this 19 May 10:16
b583392

Update: After our 5.4.1 release yesterday, the symfony/yaml package had a security release today. There is a patched version with the updated yaml dependency: https://github.com/getkirby/kirby/releases/tag/5.4.2

Note

This release is part of our new monthly security release series. Find out more about those releases and their background on our website: https://getkirby.com/buzz/security-update

🚨 Security

Pre-authentication path traversal and PHP file inclusion during user lookup

This vulnerability affects all Kirby sites on Kirby 5.3.0-5.4.0 and is independent from setup conditions and authentication.

This vulnerability is of high severity for all Kirby sites.

Thanks to @offset for responsibly reporting the identified issue.

Arbitrary Method Call via REST API search and collection query endpoints

This vulnerability affects all Kirby sites that might have potential attackers in the group of authenticated Panel users.

This vulnerability is of high severity for affected sites and has a high real-world impact.

Thanks to @mojamojam for responsibly reporting the identified issue.

Cross-site scripting (XSS) from list field content in the site frontend

This vulnerability affects all Kirby sites that use the list field or list block, when content is authored by users who may not be fully trusted. The attack requires an authenticated Panel user with update permission to any list field or list block.

This vulnerability is of high severity for affected sites.

Your Kirby sites are not affected if you don't use the list field (or blocks field with the list block) in any of your blueprints, or if every user who can edit content is fully trusted. The attack only surfaces in the site frontend (i.e. in your templates). The Panel itself is unaffected and will not execute JavaScript that was injected into list field content.

Thanks to @offset for responsibly reporting the identified issue.

Cross-site scripting (XSS) from links in KirbyTags, image blocks and imported blocks HTML in the site frontend

This vulnerability affects all Kirby sites that allow the use of the (link: …) KirbyTag, the link: parameter of the (image: …) KirbyTag, the built-in image block with a link or the HTML importer for blocks, when content is authored by users who may not be fully trusted. The attack requires an authenticated Panel user with update permission to any textarea or blocks field, or write access to content files through another vector (e.g. a frontend form or content sync pipeline). Another attack vector is the use of Html::a() or Html::link() with untrusted user input.

This vulnerability is of high severity for affected sites.

Your Kirby sites are not affected if none of the mentioned KirbyTags or block types are used, or if every user who can edit content is fully trusted. The attack only surfaces in the site frontend (i.e. in your templates). The Panel itself is unaffected and will not execute JavaScript that was injected into the textarea or blocks field content.

Thanks to @offset for responsibly reporting the identified issue.

pages.access permission is not checked during rendering of page drafts

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), via options in the model blueprint(s) or via a combination of both settings.

Your Kirby sites are not affected if you intend all users of your site to be able to access all page drafts of the site. The vulnerability can only be exploited by authenticated users. Write actions are not affected by this vulnerability.

Thanks to @adrgs for responsibly reporting the identified issue.

Content locks disclose IDs and emails of inaccessible users from users.access/list permissions

This vulnerability affects all Kirby sites that restrict the visibility of users for certain roles via the users.access or users.list permissions. A site is affected if users of a particular role are not allowed to see other users in the Panel, for example because the role's blueprint sets users.access: false or users.list: false as permission for the authenticated user role and/or as option for the target user role.

Your Kirby site is not affected if all authenticated Panel users are permitted to access and list other users. The vulnerability can only be exploited by authenticated users.

Thanks to Matteo Panzeri (@matte1782) for responsibly reporting the identified issue.

✨ Enhancements

  • New Kirby\Sane\Sane::sanitizeProseMirrorFields() method which sanitizes the value and converts non-breaking spaces to HTML entity to match ProseMirrors internal handling
  • New Kirby\Http\Url::hasDangerousScheme()

🚨 Security fixes

  • Validate user ID format and path containment in the accounts directory during user lookup with $users->find()
  • Respect page access permissions when accessing/rendering drafts in frontend
  • Remove insecure search options (sort and filter) in API routes
  • New Kirby\Toolkit\BlockAccessAttribute for model methods that must not be used by filterBy or sortBy in Collections.
  • List field values now are sanitized to protect it from XSS attacks
  • Fix information disclosure in content lock data: the locking user's email and ID now hidden from users who do not have permission to list that user
  • Ensure Kirby\Toolkit\Html::link() and Kirby\Http\Url::isAbsolute() do not allow dangerous schemes
  • The blocks HTML importer no longer imports link URLs with dangerous schemes

🐛 Bug fixes

  • Fixed using ::filter()/::filterBy() with non-default separators #8062
  • Fixed picker dialogs to respect the search: false option #8054
  • Fixed multiselect field search (thanks @lauriii) #8067
  • Fixed JSON response error showing up on throttled Panel API calls #7351
  • Imagick thumb driver: fixed preserving profiles listed in profiles option #8066
  • Improve thumbnail generation reliability by writing thumbs #4632
  • Panel file view: refresh view after replacing the file #8073
  • Prevents ghost duplicate page folders caused by stale concurrent writes after page reordering #7964
  • Fixed return type docs for  Collection::first() and Collection::last() to include null for empty collections #8094
  • Pagination is now visible in the file-browser dialog #8080
  • Fixed chunked uploads using the wrong file blueprint #8086
  • Fixed first toggles option in blocks is selectable again #8093
  • Time field: Fixed min/max validation message #8128

🚨 Breaking changes

  • Html::link() does no longer accept javascript: URLs. This is a dangerous anti-pattern with many better frontend alternatives and leaves too much space for potential attacks.

🧹 Housekeeping

  • Upgrade npm dependencies #8060

4.9.1

Choose a tag to compare

@bastianallgeier bastianallgeier released this 19 May 10:15

Update: After our 4.9.1 release yesterday, the symfony/yaml package had a security release today. There is a patched version with the updated yaml dependency: https://github.com/getkirby/kirby/releases/tag/4.9.2

🚨 Security

This is a backport of our security release for Kirby 5. For all details and vulnerabilities see: https://github.com/getkirby/kirby/releases/tag/5.4.1

We recommend all users upgrade to Kirby 5. If an upgrade is not possible, this security release is the alternative solution.

5.4.0

Choose a tag to compare

@bastianallgeier bastianallgeier released this 23 Apr 08:14
8006161

🚨 Security

Server-Side Template Injection (SSTI) via double template resolution in option rendering

This vulnerability affects all Kirby sites that use option fields (checkboxes, color, multiselect, select, radio, tags or toggles) with options from a query or API whose values may not be fully trusted. It also affects direct uses of the OptionsApi or OptionsQuery classes of Kirby's Options package from plugin or site code. The attack requires either an
attacker in the group of authenticated Panel users or user interaction of another authenticated user.

This vulnerability is of high severity for affected sites.

Your Kirby sites are not affected if you are not using any of the mentioned fields or the Options package, if all options are defined statically in the blueprints or if all dynamically gathered options are to be trusted.

Thanks to @offset for responsibly reporting the identified issue.

Page, file and user creation APIs bypass create permission check via unfiltered blueprint parameter

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.

Your Kirby sites are not affected if you intend all users of your site to be able to create pages, files and users. The vulnerability can only be exploited by authenticated users.

Thanks to @offset for responsibly reporting the identified issue.

pages.access/list and files.access/list permissions are not consistently checked in the Panel and REST API

This vulnerability affects all Kirby sites where users of a particular role have no permission to access or list pages or files (pages.access, pages.list, files.access or files.list permission is disabled). This can be due to configuration in the user blueprint(s), via options in the model blueprint(s) or via a combination of both settings.

This vulnerability is of high severity for affected sites.

Your Kirby sites are not affected if you intend all users of your site to be able to access all pages and files of the site. The vulnerability can only be exploited by authenticated users.
Write actions are not affected by this vulnerability.

Read access to site, user and role information is not gated by permissions

This vulnerability affects all Kirby sites that might have potential attackers in the group of authenticated Panel users.

This vulnerability is of high severity for affected sites.

Your Kirby sites are not affected if you intend all users of your site to be able to list and access the site model and all users and roles, including the content stored within these models.
Write actions are not affected by this vulnerability as they were gated by permissions before.

Thanks to @HuajiHD for responsibly reporting the identified issue.

XML Injection in the XML creator toolkit

This vulnerability only affects Kirby sites that use the Xml data handler (e.g. Data::encode($string, 'xml')) or the Xml::create(), Xml::tag() or Xml::value() method(s) in site or plugin code. The Kirby core does not use any of the affected methods.

If you use an affected method and cannot rule out input to these methods controlled by an attacker, we strongly recommend to update to a patch release.

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

User avatar creation, replacement and deletion are not gated by user update permissions

This vulnerability affects all Kirby sites where users of a particular role have no permission to update user information (user.update or users.update permission is disabled). This can be due to configuration in the blueprint(s) of the acting users, via options in the blueprint(s) of the target users or via a combination of both settings.

Your Kirby sites are not affected if you intend all users of your site to be able to upload, replace or delete user avatars. The vulnerability can only be exploited by authenticated users.

Page creation API bypasses changeStatus permission check via unfiltered isDraft parameter

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

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

Thanks to @offset for responsibly reporting the identified issue.

System API endpoint leaks installed version and license data to authenticated users

This vulnerability affects all Kirby sites that might have potential attackers in the group of authenticated Panel users.

Thanks to @HuajiHD and @0x-bala for responsibly reporting the identified issue.

✨ Enhancements

  • Site permissions
    • New access permission for the site
    • New Kirby\Cms\Site::isAccessible() method checking if the current user has access permission for the site
    • New static Kirby\Cms\Find::site() method returning the site object or throwingKirby\Exception\NotFoundException if the site is not accessible
    • New i18n string error.site.notAccessible added to i18n/translations/en.json
  • User permissions
    • New access and list permissions for users and the current user.
    • New Kirby\Cms\User::isAccessible() method checking if the current user has access permission for a given user
    • New Kirby\Cms\User::isListable() method checking if a user is both accessible and has list permission. Inaccessible users are implicitly not listable
    • New static Kirby\Cms\Find::users() method returning only users filtered by isListable()
  • Role permissions
    • New Kirby\Cms\Role::isAccessible() method checking if the current user has users.access or user.access permission. If the role is the same role as the user's, the user.access permissions are checked. Otherwise users.access.
    • New static Kirby\Cms\Find::role() and Kirby\Cms\Find::roles() methods returning only roles filtered by isAccessible()
    • Added a new error.role.notFound translation key.
  • Avatar permissions
    • New avatar hooks user.createAvatar, user.replaceAvatar, user.deleteAvatar (including :before and :after)
    • New User class methods: User::createAvatar(), User::replaceAvatar(), User::deleteAvatar()
    • New User rules: UserRules::createAvatar(), UserRules::replaceAvatar(), UserRules::deleteAvatar(), UserRules::validAvatar()

🚨 Security fixes

  • The GET /system API route now consistently filters the relevant set of information by current system state
  • Kirby\Cms\Find::parent() now uses Kirby\Cms\Find::site() instead of $kirby->site() for the site model lookup
  • Kirby\Cms\Api::site() now delegates to Kirby\Cms\Find::site() instead of $this->kirby->site()
  • config/api/models/System.php the title field now reads directly from $this->kirby()->site() to bypass the site.access permission check, ensuring the title is always available
  • The page.move dialog now uses Kirby\Cms\Find::site() in the submit handler, when a page gets moved to the top-level
  • Kirby\Cms\Find::user() now enforces isAccessible() on the resolved user, throwing Kirby\Exception\NotFoundException if the user exists but is inaccessible
  • API routes (config/api/routes/users.php): all `$this->user()...
Read more