github getkirby/kirby 5.4.4
on GitHub

6 hours ago

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 TOTP token verification against timing leaks using constant-time verification
  • New $helper.url.hasDangerousScheme(url) JS helper
  • New $helper.string.isEmail(string, strict) helper
  • New cookie.key option to allow setting the Kirby\Http\Cookie::$key directly from the config

🐛 Bug fixes

  • Account view: Fixed showing prev-next navigation buttons #8155 (thx @samyouel)
  • Kirby\Http\Environment now correctly extracts the for= value from the standardized Forwarded header, fixing ::isLocal() detection behind certain proxies. #8166
  • Alt+click on email links in writer fields opens a new email to this address in the default email client
  • Pasting email addresses with modern TLDs are now also converted to email links in writer fields
  • Database queries: ensure columns exist in ->where() and ->having() clauses instead of simply dropping non-existing columns from those clauses #8180
  • Fixed handling of invalid JSON in Kirby\Image\Focus::normalize() #8186
  • The (date:) KirbyTag now escapes its output to prevent HTML being injected through special characters in the tag value. Thanks to Peter Levashov (@petersevera) for his responsible disclosure and suggestion.
  • Html::gist() now only embeds Gists from gist.github.com, so it can no longer load scripts from arbitrary URLs. Thanks to Peter Levashov (@petersevera) for his responsible disclosure and suggestion.
  • Fixed blueprint field lookups with normalized field keys for mixed-case field names #8171
  • Escape attributes of Kirby\Image\QrCode::toSvg() #8185
  • Throw error when QR code data exceeds the capacity of the max version #8185
  • Fixed content meta data (editor & modified timestamp) to fall back to the current language when no active lock exists (Kirby\Content\Lock::for() uses current language for fallback) #8173
  • Prevent division-by-zero crashed in Kirby\Image\Location::num() through malformed EXIF data #8184
  • Fixed TypeError in PageTree.preselect when refs are cleared #8193
  • The quote block no longer ignores the node configuration from the blueprint. #8192

🚨 Breaking changes

  • Html::gist() (and the (gist:) tag) now ignores URLs from hosts other than gist.github.com. Sites embedding Gists from a custom host (e.g. GitHub Enterprise) can re-allow it via Kirby\Toolkit\Html::$gistDomains[] = 'gist.example.com';.
Check out latest releases or
releases around getkirby/kirby 5.4.4

Don't miss a new kirby release

NewReleases is sending notifications on new releases.

Get notifications