CVE-2026-44177 in Kirby
Summary
by MITRE • 07/17/2026
Kirby is an open-source content management system. In versions 5.3.0 and above but prior to 5.4.1, Kirby did not correctly validate the provided user ID, resulting in a path traversal vulnerability. Version 5.3.0 introduced a performance improvement to the Users collection that loaded user objects lazily when first needed. Users were queried by their ID, which was then used to locate the corresponding account directory under site/accounts. This affected the authentication API (accessible to unauthenticated requests), the users API (accessible only to authenticated users), and any other place that uses $users->find() to look up an individual user by a request-provided email or ID. As a result, an attacker could trigger arbitrary PHP file inclusion of files named index.php (for example, the main PHP files of plugins), the impact of which depends on the logic those files contain. It also allowed probing for the existence of arbitrary directories on the server, letting attackers fingerprint the server and site setup, including installed plugins and the content structure. This issue has been fixed in version 5.4.1.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 07/17/2026
The vulnerability in Kirby CMS represents a critical path traversal flaw that emerged with the introduction of lazy loading for user objects in version 5.3.0. This security issue stems from inadequate input validation when processing user identifiers within the Users collection functionality, creating a dangerous condition where attacker-controlled data directly influences file system operations. The flaw specifically affects how user IDs are processed during authentication and user management operations, making it particularly dangerous as it impacts both authenticated and unauthenticated API endpoints.
Technical exploitation of this vulnerability occurs through the improper handling of user ID parameters that are passed to the $users->find() method, which then constructs file paths based on these identifiers without proper sanitization. The system's design assumes that user IDs correspond directly to legitimate account directories under site/accounts, but attackers can manipulate these inputs to traverse the file system beyond intended boundaries. This flaw is categorized as a path traversal vulnerability under CWE-22 and aligns with ATT&CK technique T1059.007 for PHP file inclusion, allowing adversaries to access arbitrary files on the server that should remain protected.
The operational impact of this vulnerability extends far beyond simple file disclosure, as it enables comprehensive server fingerprinting and reconnaissance activities. Attackers can probe for directory structures, identify installed plugins through file existence checks, and potentially gain access to sensitive PHP files including plugin index.php files that may contain exploitable logic or configuration data. The authentication API being accessible to unauthenticated requests means that any user can attempt exploitation without prior credentials, significantly broadening the attack surface. This vulnerability also affects the broader system architecture by undermining the principle of least privilege and potentially allowing attackers to escalate their access level through careful manipulation of the user lookup mechanism.
The remediation implemented in version 5.4.1 addresses this vulnerability through proper input validation and sanitization of user identifiers before they are used in file system operations. Security best practices recommend implementing strict parameter validation, using whitelisting approaches for user ID handling, and ensuring that all external inputs are properly escaped or encoded before being used in path construction. Organizations should also implement network-based protections such as web application firewalls to detect and block suspicious path traversal patterns, while maintaining regular security updates to prevent similar vulnerabilities from arising in other components of their CMS infrastructure. The vulnerability serves as a reminder of the importance of secure coding practices when implementing lazy loading mechanisms that interact with file system operations and external inputs.