CVE-2026-71415 in Kirby
Summary
by MITRE • 08/31/2026
Kirby is an open-source content management system. From 5.0.0 until 5.5.2, Kirby's REST API chunk upload handler in src/Api/Upload.php did not run the relevant upload authorization preflight in Kirby\Api\Upload::process() before Kirby\Api\Upload::processChunk() persisted chunk data. An authenticated user with the access.panel permission enabled but with files.create, files.replace, and user/users.update permissions disabled could submit requests with an Upload-Length header and leave unfinished chunks in site/cache/.uploads for 24 hours. Repeating this process could consume attacker-controlled temporary storage, prevent other users from uploading files, or prevent site logic from storing data, although final permission checks still prevented unauthorized files from reaching the content or site/accounts directories. This issue is fixed in version 5.5.2.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 08/31/2026
The vulnerability identified in Kirby CMS versions ranging from 5.0.0 to 5.5.2 represents a significant flaw within the REST API chunk upload handler located at src/Api/Upload.php. The core technical deficiency lies in the execution order of authorization checks relative to data persistence operations. Specifically, during the file upload process, the system invokes Kirby\Api\Upload::process() which is responsible for handling multipart uploads by breaking them into chunks. However, prior to version 5.5.2, this method failed to execute the necessary preflight authorization check before calling Kirby\Api\Upload::processChunk(). This function call directly persists chunk data to the file system without first verifying whether the authenticated user possesses the specific permissions required for that action. Consequently, the security boundary intended by the application's permission model is bypassed at the storage layer, allowing unauthorized write operations to occur in temporary directories even when higher-level content creation or replacement permissions are explicitly denied.
The operational impact of this flaw centers on resource exhaustion and denial of service rather than direct data exfiltration or arbitrary code execution. An authenticated user who holds the access.panel permission but lacks files.create, files.replace, and user/users.update permissions can exploit this gap to submit requests containing an Upload-Length header. This action triggers the creation of temporary chunk files in the site/cache/.uploads directory without triggering a rejection based on insufficient privileges. These unfinished chunks remain stored for twenty-four hours before being automatically cleaned up by the system's cache management routines. By repeatedly submitting such malformed or incomplete upload requests, an attacker can systematically fill the available disk space allocated to the web server or application container. This behavior constitutes a classic resource exhaustion attack vector, where the availability of the service is compromised through the consumption of temporary storage resources rather than through malicious data injection.
From a security architecture perspective, this vulnerability aligns with CWE-732: Incorrect Permission Assignment for Critical Resource, as it involves assigning write access to a critical system directory without verifying the user's intent or privileges at the correct stage of the request lifecycle. Furthermore, in the context of the MITRE ATT&CK framework, this behavior is indicative of T1496: Resource Hijacking, where an adversary uses compromised resources for their own purposes, such as storage consumption, which can lead to service disruption. Although the final permission checks successfully prevented unauthorized files from reaching sensitive directories like content or site/accounts, limiting the blast radius to a denial-of-service scenario, the ability to manipulate system state and consume infrastructure resources remains a critical availability risk that undermines the reliability of the CMS for legitimate users.
Mitigation strategies primarily involve upgrading to Kirby version 5.5.2 or later, where this logic error has been corrected by ensuring that authorization preflight checks are executed before any chunk data is persisted to disk. For organizations unable to immediately patch their environments due to dependency constraints or testing requirements, temporary mitigations should focus on implementing rate limiting at the web server or reverse proxy level for endpoints associated with file uploads and REST API interactions. Additionally, configuring stricter quotas for the site/cache/.uploads directory can limit the extent of resource exhaustion possible by an attacker. Regular monitoring of disk usage trends related to cache directories may also provide early warning indicators of such abuse patterns, allowing administrators to intervene before service degradation becomes severe.