CVE-2026-45334 in Kirby
Summary
by MITRE • 07/17/2026
Kirby is an open-source content management system. In versions prior to 4.9.1 and 5.4.1, the content-locking feature returned lock information without checking the requesting user's access permissions. 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. 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 admin account enumeration, 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. This issue has been fixed in versions 4.9.1 and 5.4.1.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 07/17/2026
The vulnerability in Kirby CMS affects content-locking functionality across versions prior to 4.9.1 and 5.4.1, creating a critical information disclosure risk through improper access control implementation. This flaw exists within the Panel's user interface where content locks are managed to prevent concurrent editing conflicts. The system maintains lock information for users currently editing models, displaying this data in the user interface to facilitate communication between editors. However, the implementation fails to validate whether requesting users possess adequate permissions before returning lock details, creating an access control bypass that allows lower-privilege authenticated users to obtain sensitive user information.
The technical flaw manifests when the content-locking mechanism returns user identifiers and email addresses without enforcing permission checks against the requesting user's role configuration. Specifically, users configured with users.access: false or users.list: false permissions can still retrieve lock information for any currently edited model regardless of their access level. This occurs because the system includes internal user email addresses and identifiers in every Panel view payload and error responses generated when attempting to edit locked models. The vulnerability exploits a fundamental weakness in the authorization model where the system assumes that all authenticated users should have access to lock information, ignoring the principle of least privilege.
The operational impact of this vulnerability extends beyond simple information disclosure, creating potential attack vectors for credential harvesting and account enumeration. Low-privilege users can systematically gather email addresses and user identifiers from administrators and higher-privileged accounts, enabling targeted phishing campaigns or credential-stuffing attacks against both the Kirby installation and external systems where users may have reused credentials. The 10-minute default lock window provides sufficient time for attackers to collect multiple data points and correlate information across different user sessions. This vulnerability directly relates to CWE-284 (Improper Access Control) and can be mapped to ATT&CK technique T1566 (Phishing) and T1580 (Tactic: Credential Access) through the enumeration and harvesting of user credentials.
Mitigation strategies should focus on implementing proper access control validation at all points where user information is returned, particularly in error responses and UI payloads. The fix implemented in versions 4.9.1 and 5.4.1 requires checking requesting user permissions before disclosing lock information, ensuring that only authorized users can access details about who currently has a model open for editing. Organizations should also consider implementing additional monitoring for unusual enumeration patterns and review their user role configurations to ensure that low-privilege accounts cannot access sensitive system information through indirect means. The vulnerability demonstrates the importance of validating access permissions at every interface point where sensitive data may be exposed, regardless of the authentication state of the requesting user.