CVE-2026-12513 in Shared Files Plugin
Summary
by MITRE • 08/28/2026
The Shared Files WordPress plugin before 1.7.67, shared-files-pro WordPress plugin before 1.7.68 do not properly sanitize a file path taken from a frontend file submission and their single-pass traversal filter is bypassable, allowing unauthenticated users to store a path that points outside the uploads directory. When the corresponding file entry is later permanently deleted, an arbitrary file on the server (such as wp-config.php) is deleted, leading to denial of service and potential site takeover.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/28/2026
The vulnerability resides within the Shared Files WordPress plugin versions prior to 1.7.67 and its premium counterpart, shared-files-pro, before version 1.7.68. This security flaw stems from insufficient input validation regarding file paths submitted by unauthenticated users through the frontend interface. The core technical issue is a path traversal vulnerability where the application fails to properly sanitize directory separators or relative path components in user-supplied data. Although the plugin implements a single-pass filter intended to restrict uploads to the designated WordPress uploads directory, this defense mechanism is fundamentally flawed due to its simplistic nature. Attackers can bypass this restriction by crafting specific file paths that exploit how the traversal logic processes nested directories or encoded characters, effectively allowing them to specify destinations outside the allowed sandboxed area.
The operational impact of this vulnerability extends beyond simple unauthorized storage. While an attacker might initially use this flaw to store malicious files in unintended locations on the server filesystem, the most critical consequence arises during file management operations. When a user requests the permanent deletion of a previously uploaded file entry through the plugin's interface, the application attempts to remove the associated physical file from the disk using the stored path. Because the stored path was not properly validated against directory boundaries at upload time, it may point to sensitive system files or configuration scripts located outside the uploads folder. Consequently, executing this deletion action results in the irreversible removal of critical server-side assets.
This capability leads directly to a severe denial of service condition for the WordPress installation. If an attacker targets essential configuration files such as wp-config.php, which contains database credentials and authentication keys, their destruction will render the site non-functional immediately. Furthermore, the ability to delete arbitrary files on the server significantly increases the risk of complete site takeover or persistent compromise. By removing security-related plugins, core integrity checks, or backup files, an attacker can weaken the defensive posture of the environment, facilitating further exploitation attempts such as remote code execution via other vectors that rely on specific file structures being present.
From a classification perspective, this vulnerability aligns with CWE-22 Improper Limitation of a Pathname to a Restricted Directory and CWE-78 OS Command Injection if the deletion mechanism involves shell commands rather than direct filesystem API calls. In terms of attack tactics, it maps to ATT&CK technique T1083 File and Directory Discovery for reconnaissance or T1485 Data Destruction as part of an impact phase in advanced persistent threats. The lack of authentication requirement makes this particularly dangerous as any visitor can trigger the initial path traversal condition without needing valid credentials.
Mitigation strategies must prioritize immediate patching to versions 1.7.67 and later for Shared Files, or 1.7.68 and later for shared-files-pro. Until patches are applied, administrators should consider disabling file deletion capabilities via frontend forms if possible, though this may not fully mitigate the risk given the nature of the flaw. Implementing strict allowlists for permitted characters in filenames and enforcing canonicalization checks before processing any path data is essential to prevent traversal attacks. Additionally, deploying a Web Application Firewall with rules specifically targeting directory traversal patterns can provide an additional layer of defense against exploitation attempts from unauthenticated actors. Regular audits of file permissions and ensuring that the web server process runs with minimal privileges can also limit the blast radius should such vulnerabilities be exploited in other contexts within the same environment.