Kirby CMS has an Arbitrary Method Call via REST API Search and Collection Query EndpointsGHSA-86rh-h242-j8xp
GHSA-86rh-h242-j8xp is a CWE-470 vulnerability in getkirby/cms. A fix is available for getkirby/cms — see the affected versions and patch details below.
Exploitation Status
No confirmed exploitation observed yet
- A successful exploit gives an attacker total control of the affected component, not partial access.
- CISA’s own triage has not observed active exploitation or public proof-of-concept code for this CVE as of its last assessment.
Exploitation and automatability from CISA’s SSVC triage for GHSA-86rh-h242-j8xp.
EPSS Exploitation Probability
Probability of exploitation in the next 30 days, from FIRST.org EPSS.
Real-World Exposure
getkirby/cms🐘getkirby/cmsReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects Packagist packages — download data is not available via public APIs for these ecosystems.
Description
TL;DR
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.
Introduction
Arbitrary method call is a type of arbitrary code execution. It is a vulnerability that allows attackers to run any commands or code of the attacker's choice on a target machine or in a target process.
Depending on the set of accessible methods, this can lead to disclosure of sensitive information or to unintended and malicious write actions.
Affected components
Kirby's data model is made up of model objects that are contained in collection objects. These collections can be queried with methods such as $collection->filter(), $collection->sort(), $collection->group(), $collection->pluck() and $collection->findBy(). Each of these methods allows to query the models contained in the collection by any accessible model attribute (field or method).
Kirby also provides endpoints in its REST API that allow to search through users or through children and files of the site or of a particular page. These endpoints allow the search, not, filter and sort queries as well as options to paginate the result. The same kind of queries can also be provided to API collections such as /<site|page|user>/blueprints, /<site|page>/children, /<model>/files, /languages, /roles, /translations, /users and /<user>/roles.
Impact
In affected releases, Kirby did not validate the model attributes that were used in the collection queries. This allowed attackers to include arbitrary model methods in their queries. This includes methods with sensitive data such as password() (disclosing the password hash) or root() (disclosing the absolute filesystem path on the server) as well as methods that perform impactful actions such as loginPasswordless() (causing a privilege escalation to another user) or delete() (deleting all queried models in one go if the authenticated user has appropriate permissions).
Patches
The problem has been patched in Kirby 4.9.1 and Kirby 5.4.1. Please update to one of these or a later version to fix the vulnerability.
In all of the mentioned releases, Kirby has added a blocklist of sensitive model methods that should not be called during collection operations and limited the query options for the affected endpoints to search and pagination.
Credits
Kirby thanks @mojamojam for responsibly reporting the identified issue.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | getkirby/cms | all versions | 4.9.1composer require getkirby/cms:^4.9.1 |
| 🐘Packagist | getkirby/cms | ≥ 5.0.0&&< 5.4.1 | 5.4.1composer require getkirby/cms:^5.4.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for getkirby/cms, including transitive dependencies — a direct dependency you never call can still pull in a vulnerable version.
Fix
Update getkirby/cms to 4.9.1 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-86rh-h242-j8xp is resolved across your whole dependency graph.
Workarounds
Close the privilege gap rather than the entry point: audit which accounts, roles and service identities can reach the affected operation, drop the component to the least privilege it actually needs, and review file and directory permissions created by earlier installs — a default left in place is what makes this reachable.
Frequently Asked Questions
Is GHSA-86rh-h242-j8xp in your dependencies?
Find it across Packagist, including transitive dependencies.