CVE-2026-105865 in Payload
Summary
by MITRE • 10/06/2026
Payload is a free and open source headless content management system. In versions before 3.90.0 and canary versions before 4.0.0-canary.34, an authenticated user who can update or delete uploads stored locally can cause file cleanup to remove unintended files outside the configured upload directory, resulting in data loss or service disruption. Deployments that restrict upload management to trusted users are less exposed. This issue is fixed in versions 3.90.0 and 4.0.0-canary.34.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/06/2026
Payload CMS contains a path traversal vulnerability within its local file storage cleanup mechanism, specifically affecting authenticated users who possess the ability to update or delete uploaded files. This security flaw arises from insufficient validation of user-supplied input during the process of removing associated media assets. When an authorized actor initiates a deletion request for a specific upload, the underlying system fails to strictly confine the operation within the designated upload directory boundaries. Consequently, if maliciously crafted file paths are utilized in conjunction with standard delete or update operations, the cleanup routine may interpret relative path components such as dot-dot-slash sequences correctly and proceed to remove files located outside the intended scope. This behavior represents a classic instance of CWE-22 Improper Limitation of a Pathname to a Restricted Directory, where the application does not adequately sanitize inputs before using them in file system operations.
The operational impact of this vulnerability is significant for deployments that store media locally rather than utilizing external object storage services with restricted permissions. An attacker who has obtained valid credentials and been granted upload management privileges can exploit this flaw to delete arbitrary files on the server hosting the Payload CMS instance. This capability leads directly to data loss, as critical configuration files, application code, or other sensitive documents residing in parent directories may be permanently erased. Furthermore, the removal of essential system files can cause immediate service disruption by breaking dependencies required for the web server or database connections to function correctly. The severity is mitigated somewhat by the requirement that an attacker must first authenticate and hold specific permissions, which limits the attack surface to insider threats or compromised accounts rather than unauthenticated remote attackers.
This vulnerability aligns with MITRE ATT&CK technique T1083 File and Directory Discovery combined with T1485 Data Destruction, as it enables a privileged user to enumerate and subsequently destroy data outside of expected operational boundaries. The risk is particularly acute in environments where the web server process runs with elevated privileges or shares file system access with other critical services on the same host. Deployments that restrict upload management exclusively to highly trusted administrators are less exposed because the pool of potential attackers is smaller, but any compromise of such an account results in high-impact consequences due to the breadth of files accessible through path traversal.
To mitigate this risk, organizations running affected versions must immediately upgrade Payload CMS to version 3.90.0 or later for stable releases, or version 4.0.0-canary.34 and above for canary builds. These updated versions include patches that enforce strict directory confinement during file cleanup operations, ensuring that only files within the configured upload root are eligible for deletion regardless of input content. Additionally, administrators should implement defense-in-depth strategies by running application processes under restricted user accounts with minimal filesystem permissions, thereby limiting the potential blast radius even if a path traversal exploit is attempted. Regular auditing of access logs and implementing strict role-based access control policies further reduce the likelihood of unauthorized upload management actions that could trigger this vulnerability.