CVE-2026-97332 in User Private Files Plugin
Summary
by MITRE • 10/04/2026
The User Private Files WordPress plugin before 2.2.0 does not properly protect its stored private files on multisite installations, where the rewrite rule it relies on to route file requests through its access check is never reached, allowing unauthenticated users to retrieve other users' private files directly.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 10/04/2026
The vulnerability identified in User Private Files versions prior to 2.2.0 represents a critical failure in access control mechanisms within WordPress multisite environments. This plugin is designed to restrict user-uploaded media and documents so that they are accessible only by the specific users who uploaded them or authorized administrators. The core architectural flaw lies in how the plugin attempts to enforce these restrictions on server-level file requests rather than relying solely on application-layer checks. Specifically, the implementation depends on a custom rewrite rule intended to intercept direct HTTP requests for private files and route them through PHP scripts that perform authentication and authorization verification before serving content. However, this mechanism fails completely when the WordPress installation is configured as a multisite network. In such configurations, the server's URL rewriting logic prioritizes core multisite routing rules over plugin-specific rewrite directives. Consequently, any direct request to a file path associated with private storage bypasses the PHP access check entirely and serves the raw file from disk without verifying if the requester has permission to view it.
This technical deficiency results in a severe information disclosure vulnerability that allows unauthenticated attackers to retrieve sensitive data belonging to other users on the same network. Because the rewrite rule is never reached, an attacker can simply construct URLs pointing directly to private files stored within the WordPress uploads directory structure. Since no authentication token or session validation occurs during this direct file access, any individual with knowledge of a valid file path can download documents that were intended to be confidential. This impacts not only personal privacy but also organizational security if sensitive business documents are inadvertently uploaded by employees and subsequently exposed due to this misconfiguration. The scope of the impact is broad because it affects all private files stored in the affected directories, potentially including personally identifiable information, financial records, or proprietary intellectual property depending on what users have chosen to store using the plugin.
From a classification perspective, this vulnerability aligns with CWE-284 Improper Access Control and CWE-539 Information Exposure Through Web Application Logs if log files are also affected by similar routing issues, though primarily it is an access control bypass. In terms of the MITRE ATT&CK framework, this behavior corresponds to T1005 Data from Local System which describes techniques used for data staging or exfiltration where attackers retrieve sensitive information directly from local storage without triggering typical application-level security controls. The lack of proper enforcement at the web server level means that standard intrusion detection systems monitoring PHP execution may not flag these requests, making them difficult to detect through conventional application firewall rules unless specific file path patterns are monitored.
Mitigation strategies must address both immediate remediation and long-term architectural improvements. The most effective solution is to upgrade the User Private Files plugin to version 2.2.0 or later where this multisite routing issue has been resolved by adjusting how rewrite rules interact with WordPress core functions in networked environments. For organizations unable to patch immediately, temporary workarounds include restricting direct access to the uploads directory via web server configuration files such as .htaccess for Apache or nginx.conf for Nginx servers. By denying all GET requests to specific subdirectories used by the plugin unless they originate from authenticated sessions, administrators can enforce a security boundary at the infrastructure level that compensates for the application-layer flaw. Additionally, implementing strict Content Security Policy headers and ensuring that sensitive files are stored outside of publicly accessible web roots where possible adds an additional layer of defense against direct file retrieval attacks. Regular audits of plugin configurations in multisite environments are essential to ensure that custom routing rules do not conflict with core network functionality which could lead to similar exposure vulnerabilities.