GHSA-39vq-49qm-r2mc
GHSA-39vq-49qm-r2mc is a CWE-862 vulnerability in getkirby/cms. O3 Security confirms whether GHSA-39vq-49qm-r2mc is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
Kirby CMS's content locks disclose IDs and emails of inaccessible users from `users.access/list` permissions
Exploitation Status
No confirmed exploitation observed yet
- 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-39vq-49qm-r2mc.
EPSS Exploitation Probability
EPSS (Exploit Prediction Scoring System) is a daily probability model maintained by FIRST.org. It estimates the likelihood a CVE will be exploited in production environments within the next 30 days, derived from real-world threat intelligence signals.
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 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.
A 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.
Introduction
Missing authorization allows authenticated users to gain access to information they are not intended to see.
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 user permissions control which user role is allowed to perform specific actions or access specific information in the CMS. These permissions are defined for each role in the user blueprint (site/blueprints/users/...). The users.access and users.list permissions control whether users of a given role are allowed to access and list other users in the Panel. It is also possible to customize the permissions for each target role using the options feature. The permissions and options together control the authorization of user actions.
Kirby's Panel includes a content-locking feature that records which user currently has a model open for editing. This lock prevents conflicting edits by multiple users and displays the locking user's identity in the Panel UI so other users know who to contact. Internally, the locking user's email address and identifier are included in every Panel view payload and in error responses returned when a user attempts to edit a model that is currently locked by another user.
Impact
In affected releases, this lock information was returned without checking whether the requesting user had permission to access or list the locking user.
This allowed a low-privilege authenticated Panel user, whose role was configured with users.access: false or users.list: false, to learn the email address and identifier of any user who currently had a model open for editing in the Panel, including administrators and other higher-privilege users. Content locks are active for a configurable window (10 minutes by default).
The email address can allow to enumerate admin accounts, target phishing, and feed credential-stuffing attacks against the Kirby installation or other sites.
The internal user ID can be cross-referenced with other endpoints once the requester has obtained a higher privilege through unrelated means.
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 the mentioned releases, the lock information is now filtered based on the requesting user's permissions. The identity of the locking user is hidden when the requesting user does not have permission to access or list that user.
Credits
Kirby thanks Matteo Panzeri (@matte1782) for responsibly reporting the identified issue.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🐘Packagist | getkirby/cms | all versions | 4.9.1 |
| 🐘Packagist | getkirby/cms | ≥ 5.0.0&&< 5.4.1 | 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. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
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-39vq-49qm-r2mc is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-39vq-49qm-r2mc is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-39vq-49qm-r2mc. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-39vq-49qm-r2mc in your dependencies?
O3 detects GHSA-39vq-49qm-r2mc across Packagist dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.